From nobody Mon Jan 2 05:04: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 CAB511295D2 for ; Mon, 2 Jan 2017 05:04:17 -0800 (PST) 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 xQQ3lpo6WD06 for ; Mon, 2 Jan 2017 05:04:16 -0800 (PST) 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 2208A1294F0 for ; Mon, 2 Jan 2017 05:04:15 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v02D3xvY002827 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Jan 2017 15:03:59 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v02D3wXB005792; Mon, 2 Jan 2017 15:03:58 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22634.20414.701252.859119@fireball.acr.fi> Date: Mon, 2 Jan 2017 15:03:58 +0200 From: Tero Kivinen To: Michael Richardson In-Reply-To: <2827.1483240622@obiwan.sandelman.ca> References: <8194C08F-F2F9-4B2E-B061-A02106969884@vigilsec.com> <22629.2793.418553.140726@fireball.acr.fi> <7633.1483030288@obiwan.sandelman.ca> <22630.28994.951210.861178@fireball.acr.fi> <2827.1483240622@obiwan.sandelman.ca> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 5 min Archived-At: Cc: IETF IPsec , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 13:04:17 -0000 Michael Richardson writes: > > Tero Kivinen wrote: > > That is why I think it is important that we do detect the failures > > correctly. > > >> > SK_d provides quantum resistance for the IPsec SAs and Child IKE > >> SAs. > The SK_pi and SK_pr provides key verification, meaning that > >> incorrect > PPKs will result AUTHENTICATION_FAILURE notification, > >> instead of just > wrong keys. > >> > >> Would it be reasonable to create some token/nonce from something > >> before the PPK is mixed in such that we could recognize the different > >> AUTH FAILUREs, or does that create too much of an oracle for testing > >> PPKs? > > > I think it is better to keep the AUTHENTICATION_FAILURE to mean both, > > i.e., not provide an oracle. > > okay, but can we determine the mismatch enough to log it? Depends how we do it. If we change the SK_pi and SK_pr keys, then no. The key we use for MACedIDFor* is different, and output of that will get to be part of *SignedOctets, thus when responder verifies the signature or the MAC of with secret key it will simply get failure, so there is no way of knowing whether it was PPK failure or whether it was some other failure. This also means there is no way of the attacker to use the timing to find out whether it was PPK failure or other authentication failure, making it safe... If we do some other kind of verification for PPK (for example calculate some separate hash that we send out), then most likely the attacker will also know which kind of authentication failure it was... -- kivinen@iki.fi From nobody Wed Jan 4 15:00: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 A69C6129443; Wed, 4 Jan 2017 15:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 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=-3.1, 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 Ug4XsUV2xi0W; Wed, 4 Jan 2017 15:00:17 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530C212940B; Wed, 4 Jan 2017 15:00:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=912; q=dns/txt; s=iport; t=1483570817; x=1484780417; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=owNzxeMco06cWo+3dWRY8eq+cM3GJHM0P6hWgRMcUzI=; b=S9mOZCG64G2BSVtPmJB2kEYkh4beOE9lSsKE+Tx5RQL2kvcTakdumNi4 EeSRDKgHSUM5NR2hw0P39DjNt0d5OGnC6C8/8y06nvWyfb33NkpwVPPXZ 7f468bdQleJ7AfRC3+lwZbIvF8duhLfoRJvm83QvK74gM3J4ygEWP707S E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B5AQDXfW1Y/5BdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzgBAQEBAR9fgRONUKF9hFMyWYIPgggqhXgcgT4/FAECAQEBAQEBAWM?= =?us-ascii?q?dC4USEUUSASICJgIEMBUSBA6IdQ6vRIIliikBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEYBYELhzwIiiItgjEFmwkBhlWFM4U4gV4YhQiJW4d/ikABHziBKy4OAYVUiBe?= =?us-ascii?q?BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,317,1477958400"; d="scan'208";a="190353503" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jan 2017 23:00:16 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v04N0Flk019052 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Jan 2017 23:00:16 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 4 Jan 2017 18:00:14 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Wed, 4 Jan 2017 18:00:15 -0500 From: "Brian Weis (bew)" To: "ipsec@ietf.org" Thread-Topic: GDOI GROUPKEY-PUSH Acknowledgment Message Thread-Index: AQHSZt5P5+hsHFfKUkuw0QvvNkcdlw== Date: Wed, 4 Jan 2017 23:00:14 +0000 Message-ID: <7D8F64E3-7B45-4141-95ED-87E2F503EB71@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.222.253] Content-Type: text/plain; charset="utf-8" Content-ID: <3D70B71214DF9F4A8EA0DD62D63AA1DE@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "msec@ietf.org" Subject: [IPsec] GDOI GROUPKEY-PUSH Acknowledgment Message X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 23:00:18 -0000 R3JlZXRpbmdzLA0KDQpJbiBTZW91bCB0aGVyZSB3YXMgYSBwcmVzZW50YXRpb24gb24gdGhlIEdE T0kgR1JPVVBLRVktUFVTSCBBY2tub3dsZWRnbWVudCBNZXNzYWdlIChodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC13ZWlzLWdkb2ktcmVrZXktYWNrLyksIGFuIHVwZGF0ZSB0 byBSRkMgNjQwNyAoR0RPSSkg4oCUIGEgZ3JvdXAga2V5IG1hbmFnZW1lbnQgcHJvdG9jb2wgdXNp bmcgSUtFdjEuIEdET0kgd2FzIG9yaWdpbmFsbHkgbWFuYWdlZCBieSB0aGUgTVNFQyBXRywgd2hp Y2ggaXMgbm8gbG9uZ2VyIGFjdGl2ZS4gVGhlIHF1ZXN0aW9uIHdhcyBhc2tlZCBhcyB0byB3aGV0 aGVyIHRoZXJlIHdhcyBhbnkgaW50ZXJlc3QgaW4gdGhlIElQU0VDTUUgd29ya2luZyBncm91cCBp biB0aGlzIHdvcmssIGFuZCB0aGUgYXV0aG9ycyB3ZXJlIGFza2VkIHRvIHRha2UgdGhlIHF1ZXN0 aW9uIHRvIHRoaXMgbGlzdC4gUGxlYXNlIHJlc3BvbmQgaWYgeW91IGJlbGlldmUgdGhlIGRyYWZ0 IHNob3VsZCBiZSBtYW5hZ2VkIHdpdGhpbiBJUFNFQ01FLCByYXRoZXIgdGhhbiBhcyBhbiBBRCBz cG9uc29yZWQgZHJhZnQgKHdoaWNoIGlzIHRoZSBhbHRlcm5hdGl2ZSBwbGFuKS4NCg0KVGhhbmtz LA0KVW1lc2gsIE5pbGVzaCwgVGhvbWFzLCBhbmQgQnJpYW4sIA== From nobody Thu Jan 5 14:49:09 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 5E9301296EC; Thu, 5 Jan 2017 14:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 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=-3.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hDt7IMGCaqp; Thu, 5 Jan 2017 14:49:02 -0800 (PST) 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 00EAB129460; Thu, 5 Jan 2017 14:49:01 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tvjXV6dmqz3DG; Thu, 5 Jan 2017 23:48:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1483656538; bh=GMgsydjBh3ujhiaO2CfYvhkIMgEFaqpBbjMES/CDRsk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=AZwlD0HacvHsh/TjgCKZnXLzkxorWk4ES31kUxIML1mKWuoEgRaT5nCarDNuqubhD Pf405LMqM4oVIRdPS+WnihJpZVsBQXfFw1JKM/ZNoZGTaaXP5BENiw9Tv85BdpZlHG IpI448znMYW8qUkPzgRvDGRIMbc8u8qSbAbnyRiE= 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 gbRJoV5RYS1k; Thu, 5 Jan 2017 23:48:56 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 5 Jan 2017 23:48:56 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E89C161A45; Thu, 5 Jan 2017 17:48:53 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca E89C161A45 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D107B4942C65; Thu, 5 Jan 2017 17:48:53 -0500 (EST) Date: Thu, 5 Jan 2017 17:48:53 -0500 (EST) From: Paul Wouters To: "Brian Weis (bew)" In-Reply-To: <7D8F64E3-7B45-4141-95ED-87E2F503EB71@cisco.com> Message-ID: References: <7D8F64E3-7B45-4141-95ED-87E2F503EB71@cisco.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "ipsec@ietf.org" , "msec@ietf.org" Subject: Re: [IPsec] GDOI GROUPKEY-PUSH Acknowledgment Message X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 22:49:03 -0000 On Wed, 4 Jan 2017, Brian Weis (bew) wrote: > > In Seoul there was a presentation on the GDOI GROUPKEY-PUSH Acknowledgment Message (https://datatracker.ietf.org/doc/draft-weis-gdoi-rekey-ack/), an update to RFC 6407 (GDOI) — a group key management protocol using IKEv1. GDOI was originally managed by the MSEC WG, which is no longer active. The question was asked as to whether there was any interest in the IPSECME working group in this work, and the authors were asked to take the question to this list. Please respond if you believe the draft should be managed within IPSECME, rather than as an AD sponsored draft (which is the alternative plan). Is 6407 actually implemented for IKEv2? It really reads as an IKEv1 plugin. Similarly, this also seems like an IKEv1 plugin for that plugin. I'm a little surprised 6407 is Standards Track. I wasn't around when 6407 happened. It seems like a very complicated keying protocol that just happens to be run inside IKE (although on a different port?). I'm not sure how many people within ipsecme are familiar with this and would want to work on this document. As it seems to not affect IKEv2 on port (4)500, I feel it is probably best done without adoption by the WG. Although it currently says Standards Track, so I'm not sure if it can be that and AD sponsored? Paul From nobody Fri Jan 6 08:43: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 A65F3129B76; Fri, 6 Jan 2017 08:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 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=-3.1, 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 B9AcdvpzhLlq; Fri, 6 Jan 2017 08:43:18 -0800 (PST) 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 81771129B74; Fri, 6 Jan 2017 08:43:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2854; q=dns/txt; s=iport; t=1483720998; x=1484930598; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=begZ85Yh3aD5cYZldfBxQpVTa4Gkr0d+0HKu/Ao7nok=; b=L0xmAIWrwhZbPUGu/fa4FzFmXreQPzYf2YBql4HSkeNmjYZJctgQb904 OmLIX70BiDeclVbUPj9g7Ls/VhzVFKu2ybKT4q8+nZ5xFLHGVjBpY64mc lbYBehHEQVdvRwRuxRX04OR3uzKv/UJXgYPvMVoFfg0L9agbBSSUS5MmC 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQDqyG9Y/5tdJa1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM5AQEBAQEfX4EMB41QkiGTF4IPggkqhXgCGoE7PxQBAgEBAQE?= =?us-ascii?q?BAQFjKIRoAQEBAwEjEUUFCwIBCBgCAiYCAgIwFRACBA4FiGgIDrA3giWKGAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFgQuHPIJfhBgRATMKJoJBLYIxBZUahXsBhle?= =?us-ascii?q?Kb4F3hQiJXIgJikcBHzhtTxU1DwGGFHOGOIEhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,325,1477958400"; d="scan'208";a="369554791" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jan 2017 16:43:17 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v06GhHjT006939 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Jan 2017 16:43:17 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 6 Jan 2017 11:43:16 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Fri, 6 Jan 2017 11:43:16 -0500 From: "Brian Weis (bew)" To: Paul Wouters Thread-Topic: [IPsec] GDOI GROUPKEY-PUSH Acknowledgment Message Thread-Index: AQHSZt5Pm+5bN/TfMkWEbIAgfGfqGaEq0duAgAEsLYA= Date: Fri, 6 Jan 2017 16:43:16 +0000 Message-ID: <9646944C-0EFA-4F72-B2C3-B460A1E1E937@cisco.com> References: <7D8F64E3-7B45-4141-95ED-87E2F503EB71@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.191.172] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , "msec@ietf.org" Subject: Re: [IPsec] GDOI GROUPKEY-PUSH Acknowledgment Message X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 16:43:19 -0000 SGkgUGF1bCwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KDQo+IE9uIEphbiA1LCAyMDE3 LCBhdCAyOjQ4IFBNLCBQYXVsIFdvdXRlcnMgPHBhdWxAbm9oYXRzLmNhPiB3cm90ZToNCj4gDQo+ IE9uIFdlZCwgNCBKYW4gMjAxNywgQnJpYW4gV2VpcyAoYmV3KSB3cm90ZToNCj4gDQo+PiANCj4+ IEluIFNlb3VsIHRoZXJlIHdhcyBhIHByZXNlbnRhdGlvbiBvbiB0aGUgR0RPSSBHUk9VUEtFWS1Q VVNIIEFja25vd2xlZGdtZW50IE1lc3NhZ2UgKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXdlaXMtZ2RvaS1yZWtleS1hY2svKSwgYW4gdXBkYXRlIHRvIFJGQyA2NDA3IChH RE9JKSDigJQgYSBncm91cCBrZXkgbWFuYWdlbWVudCBwcm90b2NvbCB1c2luZyBJS0V2MS4gR0RP SSB3YXMgb3JpZ2luYWxseSBtYW5hZ2VkIGJ5IHRoZSBNU0VDIFdHLCB3aGljaCBpcyBubyBsb25n ZXIgYWN0aXZlLiBUaGUgcXVlc3Rpb24gd2FzIGFza2VkIGFzIHRvIHdoZXRoZXIgdGhlcmUgd2Fz IGFueSBpbnRlcmVzdCBpbiB0aGUgSVBTRUNNRSB3b3JraW5nIGdyb3VwIGluIHRoaXMgd29yaywg YW5kIHRoZSBhdXRob3JzIHdlcmUgYXNrZWQgdG8gdGFrZSB0aGUgcXVlc3Rpb24gdG8gdGhpcyBs aXN0LiBQbGVhc2UgcmVzcG9uZCBpZiB5b3UgYmVsaWV2ZSB0aGUgZHJhZnQgc2hvdWxkIGJlIG1h bmFnZWQgd2l0aGluIElQU0VDTUUsIHJhdGhlciB0aGFuIGFzIGFuIEFEIHNwb25zb3JlZCBkcmFm dCAod2hpY2ggaXMgdGhlIGFsdGVybmF0aXZlIHBsYW4pLg0KPiANCj4gSXMgNjQwNyBhY3R1YWxs eSBpbXBsZW1lbnRlZCBmb3IgSUtFdjI/IEl0IHJlYWxseSByZWFkcyBhcyBhbiBJS0V2MQ0KPiBw bHVnaW4uIFNpbWlsYXJseSwgdGhpcyBhbHNvIHNlZW1zIGxpa2UgYW4gSUtFdjEgcGx1Z2luIGZv ciB0aGF0DQo+IHBsdWdpbi4gSSdtIGEgbGl0dGxlIHN1cnByaXNlZCA2NDA3IGlzIFN0YW5kYXJk cyBUcmFjay4NCg0KQ29ycmVjdCwgaXTigJlzIGJhc2VkIG9uIElLRXYxLiBXZSB1bmRlcnN0YW5k IHRoYXQgSVBTRUNNRSBpcyBmb2N1c2VkIG9uIElLRXYyLCBidXQgd2VyZSBhc2tlZCB0byBtYWtl IHN1cmUgdGhhdCB0aGUgd29ya2luZyBncm91cCB3YXMgbm90IGludGVyZXN0ZWQgYmVmb3JlIHRh a2luZyBhbm90aGVyIHBhdGguDQoNCj4gSSB3YXNuJ3QgYXJvdW5kIHdoZW4gNjQwNyBoYXBwZW5l ZC4gSXQgc2VlbXMgbGlrZSBhIHZlcnkgY29tcGxpY2F0ZWQNCj4ga2V5aW5nIHByb3RvY29sIHRo YXQganVzdCBoYXBwZW5zIHRvIGJlIHJ1biBpbnNpZGUgSUtFIChhbHRob3VnaCBvbg0KPiBhIGRp ZmZlcmVudCBwb3J0PykuDQoNClRoZSBnb2FsIG9mIHRoZSA2NDA3IGlzIHRvIHByb3ZpZGUga2V5 IG1hbmFnZW1lbnQgZm9yIElQIG11bHRpY2FzdCBmbG93cy4gVGhlIElLRTEgcHJvdG9jb2wgcmUt dXNlIGZvciA2NDA3IG1ha2VzIHNlbnNlIGZvciB0aGUgZGV2aWNlcyB0aGF0IHN1cHBvcnRlZCBJ UHNlYyBwcm90ZWN0aW9uIGZvciBib3RoIHVuaWNhc3QgYW5kIG11bHRpY2FzdCB0cmFmZmljLg0K DQo+IEknbSBub3Qgc3VyZSBob3cgbWFueSBwZW9wbGUgd2l0aGluIGlwc2VjbWUNCj4gYXJlIGZh bWlsaWFyIHdpdGggdGhpcyBhbmQgd291bGQgd2FudCB0byB3b3JrIG9uIHRoaXMgZG9jdW1lbnQu IEFzDQo+IGl0IHNlZW1zIHRvIG5vdCBhZmZlY3QgSUtFdjIgb24gcG9ydCAoNCk1MDAsIEkgZmVl bCBpdCBpcyBwcm9iYWJseQ0KPiBiZXN0IGRvbmUgd2l0aG91dCBhZG9wdGlvbiBieSB0aGUgV0cu DQoNClRoYW5rcy4NCg0KPiBBbHRob3VnaCBpdCBjdXJyZW50bHkgc2F5cw0KPiBTdGFuZGFyZHMg VHJhY2ssIHNvIEknbSBub3Qgc3VyZSBpZiBpdCBjYW4gYmUgdGhhdCBhbmQgQUQgc3BvbnNvcmVk Pw0KDQpLYXRobGVlbiBoYXMgYWdyZWVkIHRvIEFEIHNwb25zb3IgdGhlIGRyYWZ0IGlmIGlwc2Vj bWUgaXMgbm90IGludGVyZXN0ZWQuDQoNCkJyaWFuDQoNCj4gDQo+IFBhdWwNCg0KLS0gDQpCcmlh biBXZWlzDQpTZWN1cml0eSwgQ1NHLCBDaXNjbyBTeXN0ZW1zDQpUZWxlcGhvbmU6ICsxIDQwOCA1 MjYgNDc5Ng0KRW1haWw6IGJld0BjaXNjby5jb20NCg0K From nobody Fri Jan 6 12:51:13 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 18C891295D1 for ; Fri, 6 Jan 2017 12:51:13 -0800 (PST) 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 jBFoCTPvXNbT for ; Fri, 6 Jan 2017 12:51:11 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 657E11295CC for ; Fri, 6 Jan 2017 12:51:11 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id s140so63858775qke.0 for ; Fri, 06 Jan 2017 12:51:11 -0800 (PST) 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=69lhbWsh9aoRKc0vszYty6wu5qtXTSRikOv/RgUkhBk=; b=iAG5yeMzkjYzcy2NkYiOxr6nh+yfBtG+tKgdR7IU1XgvwZdZuYwYY2qrVJAoK0TBC8 QH7R/kd41CuqLEXsYIJjVynHtTQ3E+q1MDoM982whDjvDg5lZ8vlYTSCVa4AQlLdvwmL n6ySPlxMKvBYW376WmGskQpaRdb7ULWcuZbk6cUoV2B1l0cLEJ5U6fv+Zvfuhmi+mHyn bLaGF3J1isaLmQCVgIRs4mfFWw4GzG0icf1qt4aGzrvAdkzRR9uiM9MYj/2dhlQEsCCU jr9C7dMDLnQujkFkzZgLp/N4YDcLPE/XsqULegDxGH0Kv+oItlx5J8ad/MJgfT4V0lFG FogA== 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=69lhbWsh9aoRKc0vszYty6wu5qtXTSRikOv/RgUkhBk=; b=t/F4nBmpBm308TL0JzwIguFA4Ob3s/Il4tGpboWgK9peD0PkUU3Xq71hgv/xiNctf5 yxkobNFMrAV1Jm28f9cZD7XbsfK8FA6Ud5ILj/EEXVey9W6K8sLKSMgLPEHj8uZb+Gfo 3G1BeCxlpKKs4obh74cjLEVh8Qf6r3JrKAquWbKbWG9ujjiVxW/+oif/ieJ256xr2QyB 22en4h7B5r903VK+/3O4FGWoZYY/e2BrAgo2ZnIEeGjGcknF/No2OQA8ryX4lrPrF43n V7UMYezR3kuz4GXZn5528iUP0IMgz6CFASFh/YK81ENhX07aQuXatRwRp5ojuC9jphm/ 8h+Q== X-Gm-Message-State: AIkVDXL7Fd0+urdVGzSPzMlPAXYFnSJ04y9JNQubhgA0wqKZkHRiKMXRT+BqphsnBWChTcPGYNZC+oY874JVKw== X-Received: by 10.55.215.202 with SMTP id t71mr14831397qkt.114.1483735870593; Fri, 06 Jan 2017 12:51:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.161.101 with HTTP; Fri, 6 Jan 2017 12:51:10 -0800 (PST) In-Reply-To: References: From: Kathleen Moriarty Date: Fri, 6 Jan 2017 15:51:10 -0500 Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary=001a1149971e81e6040545732d77 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 20:51:13 -0000 --001a1149971e81e6040545732d77 Content-Type: text/plain; charset=UTF-8 Hello, I never got an answer as to whether or not I should wait on the last call, so I pushed it through. No comments came in during the holiday period. Should last call be extended? Or does the WG feel the reason was because the document is ready? If the latter then I'll get it ready for an IESG telechat. I'd prefer to put it on 2/2/2017 as there are already a fair number of documents on the telechat in 2 weeks. Thanks, Kathleen On Fri, Dec 16, 2016 at 3:44 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hi Paul, > > Thanks for your response and sorry for my delayed response. > > On Mon, Dec 12, 2016 at 1:10 PM, Paul Wouters wrote: > >> On Fri, 9 Dec 2016, Kathleen Moriarty wrote: >> >> Hello, >>> Thanks for your work on draft-ietf-ipsecme-rfc4307bis. I reviewed the >>> draft and just have a few questions, the first is a nit. >>> >>> >>> Nit: >>> In the second paragraph of 1.3, you can drop the last two words of this >>> sentence as they are redundant: >>> >>> This document does not give any recommendations for the use of >>> algorithms, it only gives implementation recommendations for >>> implementations. >>> >> >> Will do if we do a new draft version, or else will remind RFC editor of >> it. > > > Great. > >> >> >> In section 3.2 & 3.3, why isn't there a bigger jump down to SHOULD or >>> SHOULD- for: >>> >>> PRF_HMAC_SHA1 | MUST- | >>> >>> | AUTH_HMAC_SHA1_96 | MUST- The justifications seems like a bigger >>> jump would be appropriate. >>> >> >> In 4307 itself, we only had one MUST and that was SHA1. The SHOULD+ >> candidate was AES_XCBC but it was been overtaken in reality by SHA2. >> And AESPRF/AES_MAC is not as widely implemented (example: not >> available in NSS) so even those implementors who picked the MUST >> and SHOULD algorithm only have SHA1 and AESPRF/AES_MAC. If a 4307bis >> implementation only implements the MUST algorithms, it would not interop >> with a 4307 implementation that implemented all the MUST and SHOULDs, >> if we made SHA1 a SHOULD- or less. >> >> I think the available options we have are MUST- or SHOULD-. I think >> MAY or SHOULD NOT would lead to interoperability issues. I think the >> MUST- is still the best choice. >> >> Note also that all SHA1 use here is still safe (HMAC and PRF are >> different from plain SHA1) >> >> Note though that I would like to keep the status for Type 2 and Type 3 >> the same, because all sane implementations will use the same INTEG and >> PRF algorithms for a given IKE session, so these two are tightly >> coupled. > > > Yeah, I knew it was fine, but the justification provided was enough to > drop it further, so I wanted to poke at that a bit as it'll take the next > update to drop it further. If that's what the WG agreed to, that's fine. > I'll push this through to IETF last call unless the WG wants me to wait > until after the holidays. > > Thank you, > Kathleen > >> >> >> Paul >> > > > > -- > > Best regards, > Kathleen > -- Best regards, Kathleen --001a1149971e81e6040545732d77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I never got an answer as to whet= her or not I should wait on the last call, so I pushed it through.=C2=A0 No= comments came in during the holiday period.=C2=A0 Should last call be exte= nded?=C2=A0 Or does the WG feel the reason was because the document is read= y?=C2=A0 If the latter then I'll get it ready for an IESG telechat.=C2= =A0 I'd prefer to put it on 2/2/2017 as there are already a fair number= of documents on the telechat in 2 weeks.

Thanks,<= /div>
Kathleen

On Fri, Dec 16, 2016 at 3:44 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Hi Paul,

Thanks f= or your response and sorry for my delayed response.

On Mon, Dec 12, 2016= at 1:10 PM, Paul Wouters <paul@nohats.ca> wrote:
On Fri, 9 Dec 2016, Kathleen Moriarty wrote:

Hello,
Thanks for your work on draft-ietf-ipsecme-rfc4307bis.=C2=A0 I reviewe= d the draft and just have a few questions, the first is a nit.


Nit:
In the second paragraph of 1.3, you can drop the last two words of this sen= tence as they are redundant:

=C2=A0 =C2=A0This document does not give any recommendations for the use of=
=C2=A0 =C2=A0algorithms, it only gives implementation recommendations for =C2=A0 =C2=A0implementations.

 Will do if we do a new draft version, or else will remind RFC editor of it.=

Great.=C2=A0
=


In section 3.2 & 3.3, why isn't there a bigger jump down to SHOULD = or SHOULD- for:

PRF_HMAC_SHA1=C2=A0 =C2=A0 =C2=A0| MUST-=C2=A0 =C2=A0 |

| AUTH_HMAC_SHA1_96=C2=A0 =C2=A0 =C2=A0 | MUST- The justifications seems li= ke a bigger jump would be appropriate.

 In 4307 itself, we only had one MUST and that was SHA1. The SHOULD+
candidate was AES_XCBC but it was been overtaken in reality by SHA2.
And AESPRF/AES_MAC is not as widely implemented (example: not
available in NSS) so even those implementors who picked the MUST
and SHOULD algorithm only have SHA1 and AESPRF/AES_MAC. If a 4307bis
implementation only implements the MUST algorithms, it would not interop with a 4307 implementation that implemented all the MUST and SHOULDs,
if we made SHA1 a SHOULD- or less.

I think the available options we have are MUST- or SHOULD-. I think
MAY or SHOULD NOT would lead to interoperability issues. I think the
MUST- is still the best choice.

Note also that all SHA1 use here is still safe (HMAC and PRF are
different from plain SHA1)

Note though that I would like to keep the status for Type 2 and Type 3
the same, because all sane implementations will use the same INTEG and
PRF algorithms for a given IKE session, so these two are tightly
coupled.

Yeah, I knew it was fine, b= ut the justification provided was enough to drop it further, so I wanted to= poke at that a bit as it'll take the next update to drop it further.= =C2=A0 If that's what the WG agreed to, that's fine.=C2=A0 I'll= push this through to IETF last call unless the WG wants me to wait until a= fter the holidays.

Thank you,
Kathleen= =C2=A0


Paul



--

Best regards,
Kathleen



--
Best regards,
Kathleen
--001a1149971e81e6040545732d77-- From nobody Fri Jan 6 12:56: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 755D5129EBD for ; Fri, 6 Jan 2017 12:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 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=-3.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnDV_xIcn2DY for ; Fri, 6 Jan 2017 12:56:39 -0800 (PST) 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 5E9CA129EAB for ; Fri, 6 Jan 2017 12:56:39 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3twH0N0Q3Xz3Tp; Fri, 6 Jan 2017 21:56:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1483736196; bh=GVbYDx20ypIubbacfXM0kvUXuxQIeZFHyIJkYS2gyd4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=K/pXffACDFyAElr/l8H9P6KFEra6XlkKlx5igo8ev7+6W/V545qmnmHELBN3Y1T22 S8z+wpmznlJf+2EV+PnvsNivOGg01EY7haCCO2aTAzrd5iZXF3S9BwJL9DFeHJPEeH /0eeCSiIcLOtUj8WgCK0okEfqf6RyJfett82pwlo= 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 Vqggh5q31szI; Fri, 6 Jan 2017 21:56:34 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 6 Jan 2017 21:56:34 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1F9F4CA34A9; Fri, 6 Jan 2017 15:56:31 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 1F9F4CA34A9 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 074ED4942C7F; Fri, 6 Jan 2017 15:56:30 -0500 (EST) Date: Fri, 6 Jan 2017 15:56:30 -0500 (EST) From: Paul Wouters To: Kathleen Moriarty In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 20:56:40 -0000 On Fri, 6 Jan 2017, Kathleen Moriarty wrote: > I never got an answer as to whether or not I should wait on the last call, so I pushed it through.  No comments > came in during the holiday period.  Should last call be extended?  Or does the WG feel the reason was because the > document is ready?  If the latter then I'll get it ready for an IESG telechat.  I'd prefer to put it on 2/2/2017 > as there are already a fair number of documents on the telechat in 2 weeks. If you schedule it for 2/2 then I guess we can give people another two weeks for comments? Although I'm not sure if that means we will get more comments :) Paul From nobody Fri Jan 6 13:01:14 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 BFB45129ED8 for ; Fri, 6 Jan 2017 13:01:11 -0800 (PST) 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 6D3oR3XMvxmK for ; Fri, 6 Jan 2017 13:01:10 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 631BF129ECC for ; Fri, 6 Jan 2017 13:01:10 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id l7so40558464qtd.1 for ; Fri, 06 Jan 2017 13:01:10 -0800 (PST) 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=wG2Nwe6iTbrk5HYs/eLuHKaib94F9/FURnCtpdvL1M4=; b=V5cskwHkdSpHv7omzzg9TiPkFFCY7nelEdN1VLMiRQ01jgv5UEGFwa6l9XGfDu6Fxw 2jnaYnDQdi1+pYGzKGHlGsbahiSo9z+6cYhkOAOcTercMFtF9NIwRukTr0G70N53xH3D vyRvLbUmeQW787B3nA12HV2ahqMfsxlozs9i1E6NHk41czuOlXlsj+BGZbUL8+8SITV0 Uj/JrjxKOG+NhsNJnQqCDLHC2vPxQntaNVWCEVTRybH/aQOj6nHcyi8K1I76etptdEPA a1yBxrygWvW1VMSJoULbpM8VcmPkeLHxYCV1BCchzbJufF0jvK6+QwxsfDGj8lDxtbN/ 1qfw== 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=wG2Nwe6iTbrk5HYs/eLuHKaib94F9/FURnCtpdvL1M4=; b=GaRvgxYMBa/eqenOB1wMzjMlWAKJWVNyB4sgBFbE6h5ML8yVW4KBg2LYf6ps9uk59x 4yfYMJY7TAvYTPBV5WTEJVZ2wUSf6u5J2ZrdA9E3FmRF8zLGaFqmbzS0CVo8M0KNZBx9 FQNYK4l/wOQpuMEQ4UmphU+tb5gczQ3RkiXoe19s6HSznhQm4HBwssT5fM/MdK75Smfm T7zmBgzjxMyu+eAeLE7nsrJjDHp9T61o/06KqEE/toOIbiqrjUM+swKzS5NeTpFDrCUm WyR+LGF53TdiROrWtjHXyJgrDmc5G0n7P5HnF4LDcfXHi4Sz9kXwP4YGAb5xgnL/Wb/d uGmQ== X-Gm-Message-State: AIkVDXK+fDYauBuyo3rctjPWd1X8lHgH4gQBxz30brUiwWwt17NOip3g/PmW5LfxJAAdTLP9XyxfuQDB5iYWfA== X-Received: by 10.200.43.166 with SMTP id m35mr80495113qtm.261.1483736469352; Fri, 06 Jan 2017 13:01:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.161.101 with HTTP; Fri, 6 Jan 2017 13:01:09 -0800 (PST) In-Reply-To: References: From: Kathleen Moriarty Date: Fri, 6 Jan 2017 16:01:09 -0500 Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary=001a1145ecfc323908054573515d Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 21:01:12 -0000 --001a1145ecfc323908054573515d Content-Type: text/plain; charset=UTF-8 On Fri, Jan 6, 2017 at 3:56 PM, Paul Wouters wrote: > On Fri, 6 Jan 2017, Kathleen Moriarty wrote: > > I never got an answer as to whether or not I should wait on the last call, >> so I pushed it through. No comments >> came in during the holiday period. Should last call be extended? Or >> does the WG feel the reason was because the >> document is ready? If the latter then I'll get it ready for an IESG >> telechat. I'd prefer to put it on 2/2/2017 >> as there are already a fair number of documents on the telechat in 2 >> weeks. >> > > If you schedule it for 2/2 then I guess we can give people another two > weeks for comments? Although I'm not sure if that means we will get > more comments :) I'm not sure we'll get more either. Is 2/2 okay or is there any rush for this draft? Thanks! > > > Paul > -- Best regards, Kathleen --001a1145ecfc323908054573515d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 6, 2017 at 3:56 PM, Paul Wouters <paul@nohats.ca> wrote:
On Fri, 6 Jan = 2017, Kathleen Moriarty wrote:

I never got an answer as to whether or not I should wait on the last call, = so I pushed it through.=C2=A0 No comments
came in during the holiday period.=C2=A0 Should last call be extended?=C2= =A0 Or does the WG feel the reason was because the
document is ready?=C2=A0 If the latter then I'll get it ready for an IE= SG telechat.=C2=A0 I'd prefer to put it on 2/2/2017
as there are already a fair number of documents on the telechat in 2 weeks.=

If you schedule it for 2/2 then I guess we can give people another two
weeks for comments? Although I'm not sure if that means we will get
more comments :)
I'm not sure we'll get more eithe= r.=C2=A0 Is 2/2 okay or is there any rush for this draft?

Thanks!=C2=A0


Paul



--

Best regards,
Kathleen
--001a1145ecfc323908054573515d-- From nobody Sun Jan 8 11:21:57 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 4D0E2124281; Sun, 8 Jan 2017 11:21:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148390331227.769.8712272168699079806.idtracker@ietfa.amsl.com> Date: Sun, 08 Jan 2017 11:21:52 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc7321bis-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 19:21:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Authors : Daniel Migault John Mattsson Paul Wouters Yoav Nir Tero Kivinen Filename : draft-ietf-ipsecme-rfc7321bis-01.txt Pages : 13 Date : 2017-01-08 Abstract: This document updates the Cryptographic Algorithm Implementation Requirements for ESP and AH. The goal of these document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. This document obsoletes RFC 7321 on the cryptographic recommendations only. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc7321bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc7321bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc7321bis-01 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 Sun Jan 8 11:25: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 7EF0612964C for ; Sun, 8 Jan 2017 11:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199] 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 CMsT8Ra5X_Bx for ; Sun, 8 Jan 2017 11:25:18 -0800 (PST) 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 4525E1295C6 for ; Sun, 8 Jan 2017 11:25:18 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3txSt32Cpkz3M2; Sun, 8 Jan 2017 20:25:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1483903515; bh=doio6OfFBSBDkqiSdcpLiQPTKI51+k0Lig2AdHOnkMI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=tw0p4kQaRw3HBMZgk+Prf06LApKkfng06UL4QFWX/HwnIEQwPyEDC/XsrS3EuCE+4 MhZrDV3T4nBdKNMje8BOY52hoDTNirvS4IA/8l9OztXpJJZimB1Sjl87N8Z5TQY8KR kDC7/glx3ozAmW6EC+302qXAZ/zbBy01PjBxROkE= 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 f-Vpc5pC8O_s; Sun, 8 Jan 2017 20:25:13 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 8 Jan 2017 20:25:13 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id F4079CA34B6; Sun, 8 Jan 2017 14:25:09 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca F4079CA34B6 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E0C424942C68; Sun, 8 Jan 2017 14:25:09 -0500 (EST) Date: Sun, 8 Jan 2017 14:25:09 -0500 (EST) From: Paul Wouters To: Tero Kivinen In-Reply-To: <22601.21730.53034.495290@fireball.acr.fi> Message-ID: References: <22600.13475.748226.49629@fireball.acr.fi> <876523B00C3F9D47BFD2B654D63DBF92BEB50D82@US70UWXCHMBA05.zam.alcatel-lucent.com> <22601.21730.53034.495290@fireball.acr.fi> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org" , "Hu, Jun \(Nokia - US\)" Subject: Re: [IPsec] RFC4301, rfc7321bis and Manual keys X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 19:25:19 -0000 On Thu, 8 Dec 2016, Tero Kivinen wrote: >> How about a new section between section 2 and 3: >> >> Manual Keying >> >> Manual Keying should not be used as it is inherently dangerous. Without >> any keying protocol, it does not offer Perfect Forward Secrecy >> protection. Deployments tend to never be reconfigured with fresh session >> keys. It also fails to scale and keeping SPI's unique amongst many servers >> is impractical. This document was written for deploying ESP/AH using IKE >> (RFC7298) and assumes that keying happens using IKEv2. >> >> If manual keying is used anyway, ENCR_AES_CBC MUST be used, and >> ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT >> be used as these algorithms require IKE. > > I think that kind of addition the rfc7321bis would be in order. Can > you add that text and resubmit? > >> [note the first "should not" is in lower case in purpose, so we don't >> actually need to update 4301] > > Perhaps not using word "should" is better. Something like "Manual > Keying is not to be used as ...". Then we do not need to explain why > it is not uppercase SHOULD... done: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc7321bis-01 Paul From nobody Mon Jan 9 06:31: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 12F66129514 for ; Mon, 9 Jan 2017 06:31:54 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uy8EBGYOTv2X for ; Mon, 9 Jan 2017 06:31:52 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0131.outbound.protection.outlook.com [23.103.201.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97D812950B for ; Mon, 9 Jan 2017 06:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KP0m5J7MclKOIqHj4BBT85c01Z3fnLjBlN4SOvgkFX0=; b=bbhXZCBQyRzqPVEObyciKuadFO/Qi/TbTLZ/ZQP/T32v4NAev3Ib12hgQuQAw7xdYjh1Yi5fFzbeklwk1xZPgAjsL4EQlKhIpnvczOH27Yys5RxkLqxFFZTYYAZuBlVrvM3+DFcW+d0NFTHcjmh785J8gmbvkbQpx4GqH5c9lq8= Received: from BN6PR09MB1427.namprd09.prod.outlook.com (10.173.202.15) by BN6PR09MB1425.namprd09.prod.outlook.com (10.173.202.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.829.7; Mon, 9 Jan 2017 14:31:50 +0000 Received: from BN6PR09MB1427.namprd09.prod.outlook.com ([10.173.202.15]) by BN6PR09MB1427.namprd09.prod.outlook.com ([10.173.202.15]) with mapi id 15.01.0829.013; Mon, 9 Jan 2017 14:31:50 +0000 From: "Waltermire, David A. (Fed)" To: Kathleen Moriarty , "paul@nohats.ca" Thread-Topic: [IPsec] AD review of draft-ietf-ipsecme-rfc4307bis Thread-Index: AQHSUkrNg8o7s6UlrEiAEvxXPjoQEqEEoY6AgAZ0WQCAIQK7AIAAAX0AgAABTYCABEkuwA== Date: Mon, 9 Jan 2017 14:31:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-ms-office365-filtering-correlation-id: 243cd4c1-f54c-4207-5663-08d4389c3fe9 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR09MB1425; x-microsoft-exchange-diagnostics: 1; BN6PR09MB1425; 7:gp97HieivQhBfbGElvn61BkHlwZTP+djQ4i7p+QooGE2CEChB3dEf3lTf5EINhmVvMtPwGAStZMtxJ9cH5ozrSh86HJURW9GRciIfwa32WOEVA0jMZlt9xbHULc1UlE9bqqRxFidO4uCdQiJRZFeZyre78zGDjPDPrKTWEMRjZqJJsaDASzdGdRbQpirm5JCMKJSBSZlYyy3dJmoYwGd3v16wypPVE90YLSV9fx1T4RL5bUv1FhNgBwGHyDQNVeYaY6zg/4UIAUneWl7ZnhpliyCqqkmJ2w3Mt3PSza2RWNA7DuMr9Kb/dQfPz+7DmZezK5brbMT2j0Kiu2VHDe92HZIOro6X0fkC4aaBsLSaTkCWQOo3e1AIhnIqy3Kf7XI7KnQP0mbkS6rWD7wFkWd0vB0YYzldUjTJGw2RtUkW8ieV+3cP3qLCWIGUb6UmTxt4bFmVbv2+Zi0XPIbWGEUrg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558021)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:BN6PR09MB1425; BCL:0; PCL:0; RULEID:; SRVR:BN6PR09MB1425; x-forefront-prvs: 0182DBBB05 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39410400002)(39850400002)(39840400002)(377454003)(199003)(189002)(24454002)(8936002)(54356999)(2501003)(106116001)(105586002)(122556002)(86362001)(6436002)(189998001)(106356001)(93886004)(55016002)(50986999)(76176999)(38730400001)(33656002)(39060400001)(99286003)(229853002)(3280700002)(4326007)(6506006)(77096006)(230783001)(6306002)(101416001)(2906002)(7736002)(68736007)(81156014)(102836003)(3660700001)(5660300001)(81166006)(2950100002)(790700001)(54896002)(6116002)(3846002)(25786008)(19609705001)(7696004)(97736004)(2900100001)(92566002)(74316002)(66066001)(5001770100001)(8676002)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR09MB1425; H:BN6PR09MB1427.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR09MB1427FEFE4970F7DDB412AAD9F0640BN6PR09MB1427namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2017 14:31:50.3052 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR09MB1425 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 14:31:54 -0000 --_000_BN6PR09MB1427FEFE4970F7DDB412AAD9F0640BN6PR09MB1427namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S2F0aGxlZW4sDQoNCkkgYW0ganVzdCBnZXR0aW5nIGJhY2sgYWZ0ZXIgdGFraW5nIGEgbG9uZyBo b2xpZGF5LiBTb3JyeSBJIHdhcyBBRksgb24gdGhpcyBvbmUuDQoNCldlIHdhbnQgdG8gYWR2YW5j ZSByZmM3MzIxYmlzIHRvIGdvIHRocm91Z2ggdGhlIHJlbWFpbmRlciBvZiBJRVNHIHJldmlldyB3 aXRoIDQzMDdiaXMgYXMgYSBwYWlyLiBVbmZvcnR1bmF0ZWx5LCBJIHdhc27igJl0IGFibGUgdG8g Z2V0IHRoaXMgZG9uZSBiZWZvcmUgbGVhdmluZyBvbiBob2xpZGF5LiBJIG5lZWQgdG8gZG8gYSBX R0xDIG9uIHJmYzczMjFiaXMgc3RhcnRpbmcgQVNBUCB0aGlzIHdlZWsuIENhbiB5b3UgaG9sZCA0 MzA3YmlzIGZvciBhIGJpdCB0byBoYXZlIHRoZSB0d28gcnVuIGNvbmN1cnJlbnRseT8NCg0KVGhh bmtzLA0KRGF2ZQ0KDQpGcm9tOiBJUHNlYyBbbWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBLYXRobGVlbiBNb3JpYXJ0eQ0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDA2 LCAyMDE3IDQ6MDEgUE0NClRvOiBwYXVsQG5vaGF0cy5jYQ0KQ2M6IGlwc2VjQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW0lQc2VjXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pcHNlY21lLXJmYzQz MDdiaXMNCg0KDQoNCk9uIEZyaSwgSmFuIDYsIDIwMTcgYXQgMzo1NiBQTSwgUGF1bCBXb3V0ZXJz IDxwYXVsQG5vaGF0cy5jYTxtYWlsdG86cGF1bEBub2hhdHMuY2E+PiB3cm90ZToNCk9uIEZyaSwg NiBKYW4gMjAxNywgS2F0aGxlZW4gTW9yaWFydHkgd3JvdGU6DQpJIG5ldmVyIGdvdCBhbiBhbnN3 ZXIgYXMgdG8gd2hldGhlciBvciBub3QgSSBzaG91bGQgd2FpdCBvbiB0aGUgbGFzdCBjYWxsLCBz byBJIHB1c2hlZCBpdCB0aHJvdWdoLiAgTm8gY29tbWVudHMNCmNhbWUgaW4gZHVyaW5nIHRoZSBo b2xpZGF5IHBlcmlvZC4gIFNob3VsZCBsYXN0IGNhbGwgYmUgZXh0ZW5kZWQ/ICBPciBkb2VzIHRo ZSBXRyBmZWVsIHRoZSByZWFzb24gd2FzIGJlY2F1c2UgdGhlDQpkb2N1bWVudCBpcyByZWFkeT8g IElmIHRoZSBsYXR0ZXIgdGhlbiBJJ2xsIGdldCBpdCByZWFkeSBmb3IgYW4gSUVTRyB0ZWxlY2hh dC4gIEknZCBwcmVmZXIgdG8gcHV0IGl0IG9uIDIvMi8yMDE3DQphcyB0aGVyZSBhcmUgYWxyZWFk eSBhIGZhaXIgbnVtYmVyIG9mIGRvY3VtZW50cyBvbiB0aGUgdGVsZWNoYXQgaW4gMiB3ZWVrcy4N Cg0KSWYgeW91IHNjaGVkdWxlIGl0IGZvciAyLzIgdGhlbiBJIGd1ZXNzIHdlIGNhbiBnaXZlIHBl b3BsZSBhbm90aGVyIHR3bw0Kd2Vla3MgZm9yIGNvbW1lbnRzPyBBbHRob3VnaCBJJ20gbm90IHN1 cmUgaWYgdGhhdCBtZWFucyB3ZSB3aWxsIGdldA0KbW9yZSBjb21tZW50cyA6KQ0KSSdtIG5vdCBz dXJlIHdlJ2xsIGdldCBtb3JlIGVpdGhlci4gIElzIDIvMiBva2F5IG9yIGlzIHRoZXJlIGFueSBy dXNoIGZvciB0aGlzIGRyYWZ0Pw0KDQpUaGFua3MhDQoNCg0KUGF1bA0KDQoNCg0KLS0NCg0KQmVz dCByZWdhcmRzLA0KS2F0aGxlZW4NCg== --_000_BN6PR09MB1427FEFE4970F7DDB412AAD9F0640BN6PR09MB1427namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21z by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5LYXRobGVlbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSBhbSBqdXN0IGdldHRpbmcgYmFjayBhZnRl ciB0YWtpbmcgYSBsb25nIGhvbGlkYXkuIFNvcnJ5IEkgd2FzIEFGSyBvbiB0aGlzIG9uZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+V2Ugd2FudCB0byBhZHZhbmNlIHJmYzczMjFiaXMgdG8gZ28gdGhyb3VnaCB0 aGUgcmVtYWluZGVyIG9mIElFU0cgcmV2aWV3IHdpdGggNDMwN2JpcyBhcyBhIHBhaXIuIFVuZm9y dHVuYXRlbHksIEkgd2FzbuKAmXQgYWJsZSB0byBnZXQgdGhpcyBkb25lIGJlZm9yZSBsZWF2aW5n IG9uIGhvbGlkYXkuIEkNCiBuZWVkIHRvIGRvIGEgV0dMQyBvbiByZmM3MzIxYmlzIHN0YXJ0aW5n IEFTQVAgdGhpcyB3ZWVrLiBDYW4geW91IGhvbGQgNDMwN2JpcyBmb3IgYSBiaXQgdG8gaGF2ZSB0 aGUgdHdvIHJ1biBjb25jdXJyZW50bHk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRhdmU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSVBz ZWMgW21haWx0bzppcHNlYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5L YXRobGVlbiBNb3JpYXJ0eTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEphbnVhcnkgMDYsIDIw MTcgNDowMSBQTTxicj4NCjxiPlRvOjwvYj4gcGF1bEBub2hhdHMuY2E8YnI+DQo8Yj5DYzo8L2I+ IGlwc2VjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSVBzZWNdIEFEIHJldmll dyBvZiBkcmFmdC1pZXRmLWlwc2VjbWUtcmZjNDMwN2JpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEphbiA2LCAyMDE3IGF0IDM6NTYgUE0sIFBhdWwg V291dGVycyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhdWxAbm9oYXRzLmNhIiB0YXJnZXQ9Il9ibGFu ayI+cGF1bEBub2hhdHMuY2E8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9u IEZyaSwgNiBKYW4gMjAxNywgS2F0aGxlZW4gTW9yaWFydHkgd3JvdGU6PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBuZXZlciBnb3QgYW4gYW5zd2Vy IGFzIHRvIHdoZXRoZXIgb3Igbm90IEkgc2hvdWxkIHdhaXQgb24gdGhlIGxhc3QgY2FsbCwgc28g SSBwdXNoZWQgaXQgdGhyb3VnaC4mbmJzcDsgTm8gY29tbWVudHM8YnI+DQpjYW1lIGluIGR1cmlu ZyB0aGUgaG9saWRheSBwZXJpb2QuJm5ic3A7IFNob3VsZCBsYXN0IGNhbGwgYmUgZXh0ZW5kZWQ/ Jm5ic3A7IE9yIGRvZXMgdGhlIFdHIGZlZWwgdGhlIHJlYXNvbiB3YXMgYmVjYXVzZSB0aGU8YnI+ DQpkb2N1bWVudCBpcyByZWFkeT8mbmJzcDsgSWYgdGhlIGxhdHRlciB0aGVuIEknbGwgZ2V0IGl0 IHJlYWR5IGZvciBhbiBJRVNHIHRlbGVjaGF0LiZuYnNwOyBJJ2QgcHJlZmVyIHRvIHB1dCBpdCBv biAyLzIvMjAxNzxicj4NCmFzIHRoZXJlIGFyZSBhbHJlYWR5IGEgZmFpciBudW1iZXIgb2YgZG9j dW1lbnRzIG9uIHRoZSB0ZWxlY2hhdCBpbiAyIHdlZWtzLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSWYgeW91IHNjaGVkdWxlIGl0IGZv ciAyLzIgdGhlbiBJIGd1ZXNzIHdlIGNhbiBnaXZlIHBlb3BsZSBhbm90aGVyIHR3bzxicj4NCndl ZWtzIGZvciBjb21tZW50cz8gQWx0aG91Z2ggSSdtIG5vdCBzdXJlIGlmIHRoYXQgbWVhbnMgd2Ug d2lsbCBnZXQ8YnI+DQptb3JlIGNvbW1lbnRzIDopPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIG5vdCBzdXJlIHdlJ2xsIGdldCBt b3JlIGVpdGhlci4mbmJzcDsgSXMgMi8yIG9rYXkgb3IgaXMgdGhlcmUgYW55IHJ1c2ggZm9yIHRo aXMgZHJhZnQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcyEmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8 YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5QYXVsPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJy IGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0t IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2Fy ZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5L YXRobGVlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN6PR09MB1427FEFE4970F7DDB412AAD9F0640BN6PR09MB1427namp_-- From nobody Mon Jan 9 06:43: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 5B1B3129CFF for ; Mon, 9 Jan 2017 06:43:26 -0800 (PST) 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 1kTBM9erY3Ge for ; Mon, 9 Jan 2017 06:43:25 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 B4E64129CF1 for ; Mon, 9 Jan 2017 06:43:24 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id l7so88266745qtd.1 for ; Mon, 09 Jan 2017 06:43:24 -0800 (PST) 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=A+1+TzYEOr9LbR1ac+mpJblJS72HyrXvSnTu4sWXj1w=; b=k+agk1m9TtJq1kRNYxuHFQvWB5X8XEuWk21G31r4v1yv/gFTsyNnonY8xv0eaBEB4x nbL4ijJ2rX2XeqiRHJSgbMXwwn4+0U4xTl9LvRDEtUays9zq2nvkZ8JhN+n7L5HR8n38 dmvxaSLYLBbcDWdZPH6jJeM29+ARvAHs1MA4cX4MjPmhnppH9We8AXfpRRR+PrtpE1eP ScE+1Qp37IBTaUcw2yIDme+dGMuTmBe42PgSMUMGBy6RMLgerhwH9s+TsRpU6ugWUBWB NEAIxUntjCR09tA2fm5cJsiEIj8dayhLBFGojCs2kQZn1qqIUl/Pz+b20qfPqysLDSy+ QLOA== 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=A+1+TzYEOr9LbR1ac+mpJblJS72HyrXvSnTu4sWXj1w=; b=iPxRT27YmO1PCwrpTO8ZvwXgwlaH3bXYKTlQnk4p6hSNT4tKPYcG02zMgMnjuyu1nM G0eCJ4S1NXh3v16zKWZDEDZxnXqd4eFjs+rxmZnBWyPD5lvdkEgncVuVuOlBmHQy7oT0 qutJi+Wob2wuaKZKY547PHeIncxVdY2KbOjxQe5HKGQbH9vfobYtnh7otnERy1ZYg0n4 myKZ1496fkt87M7QTl9muW593S6OAy46tODFRa+MznpQbJFessKa4fTjjKHYbJpiDXku DKaRJ42uREdqbuSVCt95EiIZyhjOj7xyDEsX4Ly8Nt524J1SeffOMY+TeZNIRlsq/tvp NICA== X-Gm-Message-State: AIkVDXLFYTJ3BLOkLdNegWfoWjYjKwiBKlVai2hWJaDJrBTWLV1hgntCevqMvToy6LlweKLEcDs9NkGHs8zvpg== X-Received: by 10.237.41.36 with SMTP id s33mr7678741qtd.139.1483973003892; Mon, 09 Jan 2017 06:43:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.161.101 with HTTP; Mon, 9 Jan 2017 06:43:23 -0800 (PST) In-Reply-To: References: From: Kathleen Moriarty Date: Mon, 9 Jan 2017 09:43:23 -0500 Message-ID: To: "Waltermire, David A. (Fed)" Content-Type: multipart/alternative; boundary=001a114d3f9ec0dce40545aa6365 Archived-At: Cc: "ipsec@ietf.org" , "paul@nohats.ca" Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 14:43:26 -0000 --001a114d3f9ec0dce40545aa6365 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Dave, Yes, I can remove the telechat date and reset it when the WG os ready. With that, it seems it would be fine to add time to the IETF last call (restart). Thank you, Kathleen On Mon, Jan 9, 2017 at 9:31 AM, Waltermire, David A. (Fed) < david.waltermire@nist.gov> wrote: > Kathleen, > > > > I am just getting back after taking a long holiday. Sorry I was AFK on > this one. > > > > We want to advance rfc7321bis to go through the remainder of IESG review > with 4307bis as a pair. Unfortunately, I wasn=E2=80=99t able to get this = done > before leaving on holiday. I need to do a WGLC on rfc7321bis starting ASA= P > this week. Can you hold 4307bis for a bit to have the two run concurrentl= y? > > > > Thanks, > > Dave > > > > *From:* IPsec [mailto:ipsec-bounces@ietf.org] *On Behalf Of *Kathleen > Moriarty > *Sent:* Friday, January 06, 2017 4:01 PM > *To:* paul@nohats.ca > *Cc:* ipsec@ietf.org > *Subject:* Re: [IPsec] AD review of draft-ietf-ipsecme-rfc4307bis > > > > > > > > On Fri, Jan 6, 2017 at 3:56 PM, Paul Wouters wrote: > > On Fri, 6 Jan 2017, Kathleen Moriarty wrote: > > I never got an answer as to whether or not I should wait on the last call= , > so I pushed it through. No comments > came in during the holiday period. Should last call be extended? Or doe= s > the WG feel the reason was because the > document is ready? If the latter then I'll get it ready for an IESG > telechat. I'd prefer to put it on 2/2/2017 > as there are already a fair number of documents on the telechat in 2 week= s. > > > If you schedule it for 2/2 then I guess we can give people another two > weeks for comments? Although I'm not sure if that means we will get > more comments :) > > I'm not sure we'll get more either. Is 2/2 okay or is there any rush for > this draft? > > > > Thanks! > > > > Paul > > > > > > -- > > > > Best regards, > > Kathleen > --=20 Best regards, Kathleen --001a114d3f9ec0dce40545aa6365 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dave,

Yes, I can remove the telechat= date and reset it when the WG os ready.=C2=A0 With that, it seems it would= be fine to add time to the IETF last call (restart).

<= div>Thank you,
Kathleen

On Mon, Jan 9, 2017 at 9:31 AM, Waltermire, David A. (F= ed) <david.waltermire@nist.gov> wrote:

Kathleen,

=C2=A0

I am just getting back after taking a long holiday.= Sorry I was AFK on this one.

=C2=A0

We want to advance rfc7321bis to go through the rem= ainder of IESG review with 4307bis as a pair. Unfortunately, I wasn=E2=80= =99t able to get this done before leaving on holiday. I need to do a WGLC on rfc7321bis starting ASAP this week. Can you hold 4307= bis for a bit to have the two run concurrently?

=C2=A0

Thanks,

Dave

=C2=A0

From: IPsec [mailto:ipsec-bounces@ietf.org= ] On Behalf Of Kathleen Moriarty
Sent: Friday, January 06, 2017 4:01 PM
To: paul@nohats.= ca
Cc: ipsec@ietf.o= rg
Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc4307bis

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 6, 2017 at 3:56 PM, Paul Wouters <paul@nohats.ca> wro= te:

On Fri, 6 Jan 2017, K= athleen Moriarty wrote:

I never got an answer as to whether or not I should = wait on the last call, so I pushed it through.=C2=A0 No comments
came in during the holiday period.=C2=A0 Should last call be extended?=C2= =A0 Or does the WG feel the reason was because the
document is ready?=C2=A0 If the latter then I'll get it ready for an IE= SG telechat.=C2=A0 I'd prefer to put it on 2/2/2017
as there are already a fair number of documents on the telechat in 2 weeks.=


If you schedule it for 2/2 then I guess we can give people another two
weeks for comments? Although I'm not sure if that means we will get
more comments :)

I'm not sure we'll get more either.=C2=A0 Is= 2/2 okay or is there any rush for this draft?

=C2=A0

Thanks!=C2=A0



Paul



=C2=A0

--

=C2=A0

Best regards,

Kathleen




--
Best regards,
Kathleen
--001a114d3f9ec0dce40545aa6365-- From nobody Mon Jan 9 07:24: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 CDBAE1295D9 for ; Mon, 9 Jan 2017 07:24:14 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNPLTVD-_fru for ; Mon, 9 Jan 2017 07:24:13 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0111.outbound.protection.outlook.com [23.103.201.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34205129D68 for ; Mon, 9 Jan 2017 07:23:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oxAuCwb695fn4+T+wustJejNiejGLUv5W9aHbvP2UGc=; b=r6KHi4HR34buRxupku/1WWGHk2aM1swLp6uPyo9VBbPM2EeLXqF1eAu13m7YLsH43HP20zPo+G42wMMYsM5akk8UMHuv2KZ/zlhdwKJBkvztVHp2yo6yBD3W2GVH73OPfcjIGWSI+TuPl/o5Oy2R3igzLZo2F5yhiG/J2ZUmtiE= Received: from BN6PR09MB1427.namprd09.prod.outlook.com (10.173.202.15) by BN6PR09MB1426.namprd09.prod.outlook.com (10.173.202.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.829.7; Mon, 9 Jan 2017 15:23:56 +0000 Received: from BN6PR09MB1427.namprd09.prod.outlook.com ([10.173.202.15]) by BN6PR09MB1427.namprd09.prod.outlook.com ([10.173.202.15]) with mapi id 15.01.0829.013; Mon, 9 Jan 2017 15:23:55 +0000 From: "Waltermire, David A. (Fed)" To: Kathleen Moriarty Thread-Topic: [IPsec] AD review of draft-ietf-ipsecme-rfc4307bis Thread-Index: AQHSUkrNg8o7s6UlrEiAEvxXPjoQEqEEoY6AgAZ0WQCAIQK7AIAAAX0AgAABTYCABEkuwIAABESAgAALChA= Date: Mon, 9 Jan 2017 15:23:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-ms-office365-filtering-correlation-id: 9673cddb-8b67-4a53-9abf-08d438a386d6 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR09MB1426; x-microsoft-exchange-diagnostics: 1; BN6PR09MB1426; 7:bHB5W587K3pq9Gn/tBkI8DAIHO0eRetV+wR2hy/9SQZ7ZKo0TZkHpfD2nEx6h19VuIsNzCGhnhpfz23MVniLdVy91tE2PYcpHpUDe6N9rcrCEs6oE20AnddqkcyezyII1DYcXQmDvDPCoP+QJs4QdCIn5QXxN0gPanuBcXjD96UJM+qb0fHTeT/om/bFDi5y1X9tTYaA6RZslfr5+KdghmQPhcx3nBdtzAHscMHVdSXaui5TeFouXHmfZaxuSamKNQIWPaLmHIJRK7j6OvV2Kx6ol6fsrPO80JXZsY1sqq/gnRNCAKgc0dndW4W3YJ7pw9Qfsu0B/1Ux2609feWiocXTAa0Q/nqhn8fp3ShXd3GLDU7PeNJHX0WWoHoHK81l7m6keYRvkM0qv6IVcmfxt2EPdUUrxv71RlQwN8Itp0p3ekOLeQWljauxTpbD6lf/BS6K9HLI9SPljCHj8Mru+A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BN6PR09MB1426; BCL:0; PCL:0; RULEID:; SRVR:BN6PR09MB1426; x-forefront-prvs: 0182DBBB05 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39850400002)(39840400002)(39450400003)(377454003)(24454002)(189002)(199003)(25786008)(6436002)(3846002)(54906002)(102836003)(19609705001)(6506006)(790700001)(38730400001)(93886004)(77096006)(3280700002)(39060400001)(8936002)(55016002)(229853002)(74316002)(97736004)(86362001)(6116002)(99286003)(68736007)(81156014)(81166006)(110136003)(6916009)(2950100002)(3660700001)(105586002)(7736002)(7696004)(230783001)(4326007)(66066001)(122556002)(106116001)(106356001)(8676002)(2906002)(6306002)(33656002)(54356999)(76176999)(5660300001)(9686003)(50986999)(189998001)(2900100001)(92566002)(101416001)(54896002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR09MB1426; H:BN6PR09MB1427.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR09MB14273F5C06C96020659D5733F0640BN6PR09MB1427namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2017 15:23:55.6576 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR09MB1426 Archived-At: Cc: "ipsec@ietf.org" , "paul@nohats.ca" Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 15:24:15 -0000 --_000_BN6PR09MB14273F5C06C96020659D5733F0640BN6PR09MB1427namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S2F0aGxlZW4sDQoNClRoYW5rcy4gSGFwcHkgbmV3IHllYXIhDQoNClJlZ2FyZHMsDQpEYXZlDQoN CkZyb206IEthdGhsZWVuIE1vcmlhcnR5IFttYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBn bWFpbC5jb21dDQpTZW50OiBNb25kYXksIEphbnVhcnkgMDksIDIwMTcgOTo0MyBBTQ0KVG86IFdh bHRlcm1pcmUsIERhdmlkIEEuIChGZWQpIDxkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292Pg0KQ2M6 IHBhdWxAbm9oYXRzLmNhOyBpcHNlY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJUHNlY10gQUQg cmV2aWV3IG9mIGRyYWZ0LWlldGYtaXBzZWNtZS1yZmM0MzA3YmlzDQoNCkhpIERhdmUsDQoNClll cywgSSBjYW4gcmVtb3ZlIHRoZSB0ZWxlY2hhdCBkYXRlIGFuZCByZXNldCBpdCB3aGVuIHRoZSBX RyBvcyByZWFkeS4gIFdpdGggdGhhdCwgaXQgc2VlbXMgaXQgd291bGQgYmUgZmluZSB0byBhZGQg dGltZSB0byB0aGUgSUVURiBsYXN0IGNhbGwgKHJlc3RhcnQpLg0KDQpUaGFuayB5b3UsDQpLYXRo bGVlbg0KDQpPbiBNb24sIEphbiA5LCAyMDE3IGF0IDk6MzEgQU0sIFdhbHRlcm1pcmUsIERhdmlk IEEuIChGZWQpIDxkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292PG1haWx0bzpkYXZpZC53YWx0ZXJt aXJlQG5pc3QuZ292Pj4gd3JvdGU6DQpLYXRobGVlbiwNCg0KSSBhbSBqdXN0IGdldHRpbmcgYmFj ayBhZnRlciB0YWtpbmcgYSBsb25nIGhvbGlkYXkuIFNvcnJ5IEkgd2FzIEFGSyBvbiB0aGlzIG9u ZS4NCg0KV2Ugd2FudCB0byBhZHZhbmNlIHJmYzczMjFiaXMgdG8gZ28gdGhyb3VnaCB0aGUgcmVt YWluZGVyIG9mIElFU0cgcmV2aWV3IHdpdGggNDMwN2JpcyBhcyBhIHBhaXIuIFVuZm9ydHVuYXRl bHksIEkgd2FzbuKAmXQgYWJsZSB0byBnZXQgdGhpcyBkb25lIGJlZm9yZSBsZWF2aW5nIG9uIGhv bGlkYXkuIEkgbmVlZCB0byBkbyBhIFdHTEMgb24gcmZjNzMyMWJpcyBzdGFydGluZyBBU0FQIHRo aXMgd2Vlay4gQ2FuIHlvdSBob2xkIDQzMDdiaXMgZm9yIGEgYml0IHRvIGhhdmUgdGhlIHR3byBy dW4gY29uY3VycmVudGx5Pw0KDQpUaGFua3MsDQpEYXZlDQoNCkZyb206IElQc2VjIFttYWlsdG86 aXBzZWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aXBzZWMtYm91bmNlc0BpZXRmLm9yZz5dIE9u IEJlaGFsZiBPZiBLYXRobGVlbiBNb3JpYXJ0eQ0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDA2LCAy MDE3IDQ6MDEgUE0NClRvOiBwYXVsQG5vaGF0cy5jYTxtYWlsdG86cGF1bEBub2hhdHMuY2E+DQpD YzogaXBzZWNAaWV0Zi5vcmc8bWFpbHRvOmlwc2VjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJ UHNlY10gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaXBzZWNtZS1yZmM0MzA3YmlzDQoNCg0KDQpP biBGcmksIEphbiA2LCAyMDE3IGF0IDM6NTYgUE0sIFBhdWwgV291dGVycyA8cGF1bEBub2hhdHMu Y2E8bWFpbHRvOnBhdWxAbm9oYXRzLmNhPj4gd3JvdGU6DQpPbiBGcmksIDYgSmFuIDIwMTcsIEth dGhsZWVuIE1vcmlhcnR5IHdyb3RlOg0KSSBuZXZlciBnb3QgYW4gYW5zd2VyIGFzIHRvIHdoZXRo ZXIgb3Igbm90IEkgc2hvdWxkIHdhaXQgb24gdGhlIGxhc3QgY2FsbCwgc28gSSBwdXNoZWQgaXQg dGhyb3VnaC4gIE5vIGNvbW1lbnRzDQpjYW1lIGluIGR1cmluZyB0aGUgaG9saWRheSBwZXJpb2Qu ICBTaG91bGQgbGFzdCBjYWxsIGJlIGV4dGVuZGVkPyAgT3IgZG9lcyB0aGUgV0cgZmVlbCB0aGUg cmVhc29uIHdhcyBiZWNhdXNlIHRoZQ0KZG9jdW1lbnQgaXMgcmVhZHk/ICBJZiB0aGUgbGF0dGVy IHRoZW4gSSdsbCBnZXQgaXQgcmVhZHkgZm9yIGFuIElFU0cgdGVsZWNoYXQuICBJJ2QgcHJlZmVy IHRvIHB1dCBpdCBvbiAyLzIvMjAxNw0KYXMgdGhlcmUgYXJlIGFscmVhZHkgYSBmYWlyIG51bWJl ciBvZiBkb2N1bWVudHMgb24gdGhlIHRlbGVjaGF0IGluIDIgd2Vla3MuDQoNCklmIHlvdSBzY2hl ZHVsZSBpdCBmb3IgMi8yIHRoZW4gSSBndWVzcyB3ZSBjYW4gZ2l2ZSBwZW9wbGUgYW5vdGhlciB0 d28NCndlZWtzIGZvciBjb21tZW50cz8gQWx0aG91Z2ggSSdtIG5vdCBzdXJlIGlmIHRoYXQgbWVh bnMgd2Ugd2lsbCBnZXQNCm1vcmUgY29tbWVudHMgOikNCkknbSBub3Qgc3VyZSB3ZSdsbCBnZXQg bW9yZSBlaXRoZXIuICBJcyAyLzIgb2theSBvciBpcyB0aGVyZSBhbnkgcnVzaCBmb3IgdGhpcyBk cmFmdD8NCg0KVGhhbmtzIQ0KDQoNClBhdWwNCg0KDQoNCi0tDQoNCkJlc3QgcmVnYXJkcywNCkth dGhsZWVuDQoNCg0KDQotLQ0KDQpCZXN0IHJlZ2FyZHMsDQpLYXRobGVlbg0K --_000_BN6PR09MB14273F5C06C96020659D5733F0640BN6PR09MB1427namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4ubTQyNzE0NjA0ODA2 NzkyNzA0NDNob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6bV80MjcxNDYwNDgwNjc5MjcwNDQzaG9l bnpiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkthdGhsZWVuLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5UaGFua3MuIEhhcHB5IG5ldyB5ZWFyITxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZWdh cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RGF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiBLYXRobGVlbiBNb3JpYXJ0eSBbbWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5Lmll dGZAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSmFudWFyeSAwOSwgMjAx NyA5OjQzIEFNPGJyPg0KPGI+VG86PC9iPiBXYWx0ZXJtaXJlLCBEYXZpZCBBLiAoRmVkKSAmbHQ7 ZGF2aWQud2FsdGVybWlyZUBuaXN0LmdvdiZndDs8YnI+DQo8Yj5DYzo8L2I+IHBhdWxAbm9oYXRz LmNhOyBpcHNlY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lQc2VjXSBBRCBy ZXZpZXcgb2YgZHJhZnQtaWV0Zi1pcHNlY21lLXJmYzQzMDdiaXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgRGF2ZSw8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgSSBjYW4gcmVtb3ZlIHRoZSB0 ZWxlY2hhdCBkYXRlIGFuZCByZXNldCBpdCB3aGVuIHRoZSBXRyBvcyByZWFkeS4mbmJzcDsgV2l0 aCB0aGF0LCBpdCBzZWVtcyBpdCB3b3VsZCBiZSBmaW5lIHRvIGFkZCB0aW1lIHRvIHRoZSBJRVRG IGxhc3QgY2FsbCAocmVzdGFydCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkthdGhsZWVuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKYW4gOSwgMjAxNyBhdCA5OjMxIEFNLCBXYWx0ZXJtaXJl LCBEYXZpZCBBLiAoRmVkKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmlkLndhbHRlcm1pcmVAbmlz dC5nb3YiIHRhcmdldD0iX2JsYW5rIj5kYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292PC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+S2F0aGxlZW4sPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5JIGFtIGp1c3QgZ2V0dGluZyBiYWNrIGFmdGVyIHRha2luZyBhIGxvbmcgaG9saWRheS4g U29ycnkgSSB3YXMgQUZLIG9uIHRoaXMgb25lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+V2Ugd2FudCB0 byBhZHZhbmNlIHJmYzczMjFiaXMgdG8gZ28gdGhyb3VnaCB0aGUgcmVtYWluZGVyIG9mIElFU0cg cmV2aWV3IHdpdGggNDMwN2JpcyBhcyBhIHBhaXIuIFVuZm9ydHVuYXRlbHksIEkNCiB3YXNu4oCZ dCBhYmxlIHRvIGdldCB0aGlzIGRvbmUgYmVmb3JlIGxlYXZpbmcgb24gaG9saWRheS4gSSBuZWVk IHRvIGRvIGEgV0dMQyBvbiByZmM3MzIxYmlzIHN0YXJ0aW5nIEFTQVAgdGhpcyB3ZWVrLiBDYW4g eW91IGhvbGQgNDMwN2JpcyBmb3IgYSBiaXQgdG8gaGF2ZSB0aGUgdHdvIHJ1biBjb25jdXJyZW50 bHk/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRhdmU8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IElQc2VjIFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5p cHNlYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+S2F0aGxlZW4g TW9yaWFydHk8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKYW51YXJ5IDA2LCAyMDE3IDQ6MDEg UE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpwYXVsQG5vaGF0cy5jYSIgdGFyZ2V0 PSJfYmxhbmsiPnBhdWxAbm9oYXRzLmNhPC9hPjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFp bHRvOmlwc2VjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aXBzZWNAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSVBzZWNdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWlw c2VjbWUtcmZjNDMwN2Jpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBKYW4gNiwgMjAxNyBhdCAzOjU2IFBNLCBQ YXVsIFdvdXRlcnMgJmx0OzxhIGhyZWY9Im1haWx0bzpwYXVsQG5vaGF0cy5jYSIgdGFyZ2V0PSJf YmxhbmsiPnBhdWxAbm9oYXRzLmNhPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+T24gRnJpLCA2IEphbiAyMDE3LCBLYXRobGVlbiBNb3JpYXJ0eSB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIG5ldmVyIGdvdCBhbiBhbnN3ZXIgYXMgdG8gd2hl dGhlciBvciBub3QgSSBzaG91bGQgd2FpdCBvbiB0aGUgbGFzdCBjYWxsLCBzbyBJIHB1c2hlZCBp dCB0aHJvdWdoLiZuYnNwOyBObyBjb21tZW50czxicj4NCmNhbWUgaW4gZHVyaW5nIHRoZSBob2xp ZGF5IHBlcmlvZC4mbmJzcDsgU2hvdWxkIGxhc3QgY2FsbCBiZSBleHRlbmRlZD8mbmJzcDsgT3Ig ZG9lcyB0aGUgV0cgZmVlbCB0aGUgcmVhc29uIHdhcyBiZWNhdXNlIHRoZTxicj4NCmRvY3VtZW50 IGlzIHJlYWR5PyZuYnNwOyBJZiB0aGUgbGF0dGVyIHRoZW4gSSdsbCBnZXQgaXQgcmVhZHkgZm9y IGFuIElFU0cgdGVsZWNoYXQuJm5ic3A7IEknZCBwcmVmZXIgdG8gcHV0IGl0IG9uIDIvMi8yMDE3 PGJyPg0KYXMgdGhlcmUgYXJlIGFscmVhZHkgYSBmYWlyIG51bWJlciBvZiBkb2N1bWVudHMgb24g dGhlIHRlbGVjaGF0IGluIDIgd2Vla3MuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCklmIHlvdSBzY2hlZHVsZSBpdCBmb3IgMi8yIHRo ZW4gSSBndWVzcyB3ZSBjYW4gZ2l2ZSBwZW9wbGUgYW5vdGhlciB0d288YnI+DQp3ZWVrcyBmb3Ig Y29tbWVudHM/IEFsdGhvdWdoIEknbSBub3Qgc3VyZSBpZiB0aGF0IG1lYW5zIHdlIHdpbGwgZ2V0 PGJyPg0KbW9yZSBjb21tZW50cyA6KTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSdtIG5vdCBzdXJlIHdlJ2xsIGdldCBtb3JlIGVp dGhlci4mbmJzcDsgSXMgMi8yIG9rYXkgb3IgaXMgdGhlcmUgYW55IHJ1c2ggZm9yIHRoaXMgZHJh ZnQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UaGFua3MhJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9Im00 MjcxNDYwNDgwNjc5MjcwNDQzaG9lbnpiIj5QYXVsPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8 YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPi0tDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+S2F0aGxlZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIg Y2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0g PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgcmVnYXJk cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkth dGhsZWVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR09MB14273F5C06C96020659D5733F0640BN6PR09MB1427namp_-- From nobody Tue Jan 10 06: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 52C391294A1 for ; Tue, 10 Jan 2017 06:24:24 -0800 (PST) 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 csEUlJ_LrBGs for ; Tue, 10 Jan 2017 06:24:22 -0800 (PST) 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 7257A128DF6 for ; Tue, 10 Jan 2017 06:24:21 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v0AEOGTn022221 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 10 Jan 2017 16:24:16 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v0AEOGP4006165; Tue, 10 Jan 2017 16:24:16 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22644.61072.705632.343770@fireball.acr.fi> Date: Tue, 10 Jan 2017 16:24:16 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 61 min X-Total-Time: 38 min Archived-At: Subject: [IPsec] Review of draft-pauly-ipsecme-split-dns-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 14:24:24 -0000 This document was marked as "waiting for more reviews before taking as WG draft", so I did my review now. Here are my comments: ---------------------------------------------------------------------- In the section 1 there is text: The client device can use the internal DNS server(s) for any DNS queries within the assigned domains, while routing other DNS queries to its regular external DNS server. which would indicate that we can also use internal dns servers for other DNS queries too. Then on section 5 there is text saying: All other domain names MUST be resolved using some other external DNS resolver(s), configured independently, and SHOULD NOT be sent to the internal DNS resolver(s) listed in that CFG_REPLY message. This is bit confusing. First of all all other domain names MUST use external DNS servers, but then the requirement for ont using internal DNS is only SHOULD NOT. What is what we want there. Do we want to have clear splitting of the DNS servers, i.e. all request for internal names go to the internal servers, and never external ones, and do we want all request to external names go to the external servers, and never internal ones. I think the 1st point (I.e. all requests about internal names go to the internal servers) is something that is important for security, so it should perhaps be MUST. On the other hand the 2nd point is not about security. Quite often people can and want to use internal DNS server even for external DNS requests. So I think that should be allowed in both ways, i.e., external DNS names can be asked from either internal or external name servers, or even both. -- >From section 3.2 If the CFG_REQUEST included INTERNAL_DNS_DOMAIN attributes with non- zero lengths, the CFG_REPLY MUST NOT assign any domains in its INTERNAL_DNS_DOMAIN attributes that are not contained within the requested domains. The initiator SHOULD ignore any domains beyond its requested list. This whole thing about restricting the subdomains server can send by sending the list from client is different than what we normally do. In normal case the client sends list of suggestions for the configuration values to the server. Here the client forces server to do something. I think it would be better to say that client can send list of dns names it would like to be included, and server can then reply whatever list it has in its configuration, and client is free to ignore as many of the items from the list it likes. This way if you have originally configured company1.com to the internal dns names, and then company decides to buy another company called company2.com, teh client can still request company1.com and server can return both company1.com and company2.com in its reply. Then it is up to the client whether it will belive the list or not. -- In section 4.2 it would be useful to repeat the fact that the bytes after the Length match the DNS wire format of a DS record as specified in [RFC4034]. The bytes match, but we repeat the definition from the RFC4034, so it would be good idea to also explictly say it here, and not only in section 3.2. -- In section 5 the text: For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload, the client SHOULD use the provided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS servers as the only resolvers for the listed domains and its sub- domains and it SHOULD NOT attempt to resolve the provided DNS domains using its external DNS servers. Why is that only SHOULD. I mean if there is INTERNAL_DNS_DOMAIN specified, shouldn't the client be following it? So why it is not MUST? And in which cases the SHOULD can be broken? What are the exceptions where internal domains can be resolved from the outside dns servers (or actually failed to be resolved). -- If the initiator host is configured to block DNS answers containing IP addresses from special IP address ranges such as those of [RFC1918], the initiator SHOULD allow the DNS domains listed in the INTERNAL_DNS_DOMAIN attributes to contain these IP addresses. I think this is wrong. I think we should say that it should not block any addresses which are part of the configured INTERNAL_IP*_SUBNETS. I.e., if the vpn is not configured to pass packets to 10.0.0.0/8 network, then blocking those DNS answers is still fine. -- If a CFG_REPLY contains one or more INTERNAL_DNS_DOMAIN attributes, the client SHOULD configure its DNS resolver to resolve those domains and all their subdomains using only the DNS resolver(s) listed in that CFG_REPLY message. Again why only SHOULD? When should it ignore the instructions from the server? -- If those resolvers fail, those names SHOULD NOT be resolved using any other DNS resolvers. Should this also be MUST NOT? -- All other domain names MUST be resolved using some other external DNS resolver(s), configured independently, and SHOULD NOT be sent to the internal DNS resolver(s) listed in that CFG_REPLY message. This was already in my previous comment. -- For example, if the INTERNAL_DNS_DOMAIN attribute specifies "example.com", then "example.com", "www.example.com" and "mail.eng.example.com" MUST be resolved using the internal DNS resolver(s), but "anotherexample.com" and "ample.com" MUST be resolved using the system's external DNS resolver(s). But then in the example there is only MUSTs.... -- When an IPsec connection is terminated, the DNS forwarding must be unconfigured. The DNS forwarding itself MUST be be deleted. All cached data of the INTERNAL_DNS_DOMAIN provided DNS domainis MUST be flushed. This includes negative cache entries. Obtained DNSSEC trust anchors MUST be removed from the list of trust anchors. The This might cause security issues. I.e., if you have mail.example.com resolved using internal dns server to have IP-address of 10.0.0.1, and then someone manages to tear down the VPN connection, and suddenly all these mappings go away, the next time your mail client tries to fetch email, it does mail.example.com lookup using external DNS servers, and will get IP-address of 1.1.1.1 from ns.evil.org, then then it will connect to wrong mail server... Perhaps we should keep the mappings for some time, just in case the connection comes back few seconds later when the vpn reconnects... -- A domain that is served via INTERNAL_DNS_DOMAIN MUST NOT have indirect references to DNS records that point to other Split DNS domains that are not served via INTERNAL_DNS_DOMAIN attributes. Indirect reference RRtypes include CNAME, DNAME, MX and SRV RR's. How this going to be done? I.e., how do you convince the system adminstrator of the company1.com that adding mail.company2.com CNAME mail.company1.com is against RFC, and must not be done until all clients are configured to ask company1.com and company2.com internal dns domains? I think we can put that text in the security consideration section and say that adminstrators should take care that the CNAMES etc used in the internal domains, do not leak out to wrong domain names or something. -- In section 6: If a host connected to an authenticated IKE peer is connecting to another IKE peer that attempts to claim the same domain via the INTERNAL_DNS_DOMAIN attribute, the IKE connection should be terminated. Which of the IKE connection should be terminated? Perhaps the first connection has died and user tried to reconnect to the same server, which will of course give the same INTERNAL_DNS_DOMAIN. Tearing down that new connection and not allowing it to be formed until the first one is timed out is bit annoying. -- If the IP address value of the received INTERNAL_IP4_DNS or INTERNAL_IP6_DNS attribute is not covered by the proposed IPsec connection, then the local DNS should not be reconfigured until a CREATE_CHILD Exchange is received that covers these IP addresses. I think this is dangerous. I.e. if the server returns INTERNAL_IP4_DNS of 10.0.0.1 and INTERNAL_DNS_DOMAIN of example.com, but initial Child sa connection fails for some reason (out of resources). Next the email client trying to resolve the mail.example.com goes out to the external dns servers to find the name, instead of trying to use 10.0.0.1 dns server. Note, that when it tries to send packet to 10.0.0.1, then the IPsec will simply trigger for that packet, and will create the Child SA needed... So I think the DNS configuration should be done immediately, regardless whether the Child SA to cover those IP address is there. In properly configured system the IP-address will then trigger the SA to be created when they are first time used. -- kivinen@iki.fi From nobody Tue Jan 10 13:36: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 814051295C1 for ; Tue, 10 Jan 2017 13:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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=-3.199, 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 wty63uvCoeqx for ; Tue, 10 Jan 2017 13:36:52 -0800 (PST) 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 C713A1295BE for ; Tue, 10 Jan 2017 13:36:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5014; q=dns/txt; s=iport; t=1484084212; x=1485293812; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sKcDVj2TASGaloj2tRQpdGljf/pi/tgELkb6orTodZo=; b=SoZxNalEZKikt5Uei8NpQjlCd78BflsYdBq+ur2kdlwyjbHezqHBzJZ2 pUaMbuXZ1iZcv/Ns/qFDbBcDRm9zoCswvTIyGAcyt4Bix2L5YDEZmftBd 7dfPqR6BSRmET2f4GcJ6HFuJj8uS9A/adC5osaAOafN6sh1BiAG1UTATa M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQDFU3VY/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzoBAQEBAR+BbAeNUJIolSeCC4YiAhqBaz8UAQIBAQEBAQEBYyi?= =?us-ascii?q?EaQEBAQQjEUUMBAIBCBEEAQEBAgIjAwICAjAUAQgIAQEEAQ0FCIhosF6CJYoWA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHYELhTqEYYRdgnGCXgWIbodxikQBkUiQao5?= =?us-ascii?q?LhBIBHziBQBWGZXOHWYENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,344,1477958400"; d="scan'208";a="196630715" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jan 2017 21:36:28 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v0ALaRZe013697 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Jan 2017 21:36:27 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; Tue, 10 Jan 2017 16:36:26 -0500 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, 10 Jan 2017 16:36:26 -0500 From: "Scott Fluhrer (sfluhrer)" To: Michael Richardson , Tero Kivinen Thread-Topic: [IPsec] Quantum Resistant IKEv2 Thread-Index: AdJQCCXgkOeGxGfPROWQbtulvkq0wABlqi4AAAGlCXAEFk8mgAAHxXQAAloIPAA= Date: Tue, 10 Jan 2017 21:36:26 +0000 Message-ID: <68d87dd3d4974691b9e21294601014d7@XCH-RTP-006.cisco.com> References: <8194C08F-F2F9-4B2E-B061-A02106969884@vigilsec.com> <22629.2793.418553.140726@fireball.acr.fi> <7633.1483030288@obiwan.sandelman.ca> In-Reply-To: <7633.1483030288@obiwan.sandelman.ca> 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.61] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IETF IPsec Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 21:36:54 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1pY2hhZWwgUmljaGFyZHNv biBbbWFpbHRvOm1jcitpZXRmQHNhbmRlbG1hbi5jYV0NCj4gU2VudDogVGh1cnNkYXksIERlY2Vt YmVyIDI5LCAyMDE2IDExOjUxIEFNDQo+IFRvOiBUZXJvIEtpdmluZW4NCj4gQ2M6IFNjb3R0IEZs dWhyZXIgKHNmbHVocmVyKTsgSUVURiBJUHNlYw0KPiBTdWJqZWN0OiBSZTogW0lQc2VjXSBRdWFu dHVtIFJlc2lzdGFudCBJS0V2Mg0KPiANCj4gDQo+IFRlcm8gS2l2aW5lbiA8a2l2aW5lbkBpa2ku Zmk+IHdyb3RlOg0KPiAgICAgPj4gbyBUaGVyZSBpcyB0aGUgb3B0aW9uIGxpc3RlZCBpbiB0aGUg ZHJhZnQsIHdoZXJlIHdlIG1vZGlmeSBib3RoIHRoZQ0KPiAgICAgPj4gS0VZTUFUIGFuZCBTS0VZ U0VFRCBjb21wdXRhdGlvbnM7IHN0aXJyaW5nIGl0IGludG8gdGhlIEtFWU1BVCBpbXBsaWVzDQo+ ICAgICA+PiB0aGF0IHRoZSBJUHNlYyBTQXMgYXJlIGdlbmVyYXRlZCB3aXRoIFFSLXJlc2lzdGFu dCBrZXlpbmcgbWF0ZXJpYWwsDQo+ICAgICA+PiB3aGlsZSBzdGlycmluZyBpdCBpbnRvIHRoZSBT S0VZU0VFRCBpbXBsaWVzIHRoYXQgYW55IGNoaWxkIElLRSBTQXMNCj4gICAgID4+IGltcGxpZXMg dGhhdCBhbnkgSUtFIFNBIChvdGhlciB0aGFuIHRoZSBpbml0aWFsIG9uZSkgYWxzbyBoYXMNCj4g ICAgID4+IFFSLXJlc2lzdGFudCBrZXlpbmcgbWF0ZXJpYWwuICBUaGlzIGxhdHRlciB3YXMgZG9u ZSBzcGVjaWZpY2FsbHkgc28NCj4gICAgID4+IHRoYXQgYW4gaW1wbGVtZW50YXRpb24gY2FuIGhh dmUgcHJvdGVjdGVkIElLRSBTQXMgKGJ5IG5lZ290aWF0aW5nIGENCj4gICAgID4+IGNoaWxkIFNB IGltbWVkaWF0ZWx5KQ0KPiAgICAgPj4NCj4gICAgID4+IG8gRGFuIEhhcmtpbnMgc3VnZ2VzdGVk IHRoYXQgd2UgbW9kaWZ5IG9ubHkgdGhlIEtFWU1BVC4gIFRoaXMgaXMgYQ0KPiAgICAgPj4gc2lt cGxlciBvcHRpb24sIGFuZCB3aWxsIGNvbnRpbnVlIHRvIHByb3RlY3QgdGhlIElQc2VjIFNBczsg aG93ZXZlcg0KPiAgICAgPj4gdGhpcyBpbXBsaWVzIHRoYXQgYW55IGRhdGEgcHJvdGVjdGVkIGJ5 IHRoZSBJS0UgU0EgY291bGQgcG90ZW50aWFsbHkNCj4gICAgID4+IGJlIHJlY292ZXJlZCBieSBh IFF1YW50dW0gQ29tcHV0ZXIuDQo+IA0KPiAgICAgPiBUaGlzIGhhcyB0aGUgaXNzdWUgdGhhdCBk aWZmZXJlbmNlcyBpbiB0aGUgUFBLIHdpbGwgbm90IGJlIGRldGVjdGVkLA0KPiAgICAgPiBpLmUu LCBpZiBQUEtzIGFyZSBtaXNtYXRjaGVkIGJlY2F1c2Ugb2YgY29uZmlndXJhdGlvbiBlcnJvciwg d2UgZG8gZ2V0DQo+ICAgICA+IElLRXYyIFNBIHVwIGFuZCBydW5uaW5nLCBhbmQgd2UgY3JlYXRl IElQc2VjIENoaWxkIFNBcyB3aXRob3V0IGVycm9ycywNCj4gICAgID4gYnV0IHRoZW4gYWxsIHRy YWZmaWMgaW4gSVBzZWMgU0Egd2lsbCBzaW1wbHkgYmUgZHJvcHBlZCBhcyB0aGUga2V5aW5nDQo+ ICAgICA+IG1hdGVyaWFsIGlzIHdyb25nLg0KPiANCj4gSSB0aGluayB0aGF0IHRoaXMgaXMgYSAq SFVHRSogdXNlciBjb25maWd1cmF0aW9uIGlzc3VlLg0KPiBJdCBtZWFucyB0aGF0IHRoZSBRTSBy ZXNpc3RhbmNlIHdpbGwgYmUgdHVybmVkIG9mZiBmaXJzdCB0aGluZyB3aGVuZXZlciB0aGVyZQ0K PiBpcyBhIHByb2JsZW0uDQo+IA0KPiAgICAgPiBTS19kIHByb3ZpZGVzIHF1YW50dW0gcmVzaXN0 YW5jZSBmb3IgdGhlIElQc2VjIFNBcyBhbmQgQ2hpbGQgSUtFIFNBcy4NCj4gICAgID4gVGhlIFNL X3BpIGFuZCBTS19wciBwcm92aWRlcyBrZXkgdmVyaWZpY2F0aW9uLCBtZWFuaW5nIHRoYXQgaW5j b3JyZWN0DQo+ICAgICA+IFBQS3Mgd2lsbCByZXN1bHQgQVVUSEVOVElDQVRJT05fRkFJTFVSRSBu b3RpZmljYXRpb24sIGluc3RlYWQgb2YganVzdA0KPiAgICAgPiB3cm9uZyBrZXlzLg0KPiANCj4g V291bGQgaXQgYmUgcmVhc29uYWJsZSB0byBjcmVhdGUgc29tZSB0b2tlbi9ub25jZSBmcm9tIHNv bWV0aGluZyBiZWZvcmUNCj4gdGhlIFBQSyBpcyBtaXhlZCBpbiBzdWNoIHRoYXQgd2UgY291bGQg cmVjb2duaXplIHRoZSBkaWZmZXJlbnQgQVVUSA0KPiBGQUlMVVJFcywgb3IgZG9lcyB0aGF0IGNy ZWF0ZSB0b28gbXVjaCBvZiBhbiBvcmFjbGUgZm9yIHRlc3RpbmcgUFBLcz8NCg0KSSBiZWxpZXZl IHRoYXQgd291bGQgYmUgcmVhc29uYWJsZS4gIFdlIGFscmVhZHkgZXhjaGFuZ2Ugbm90aWZpZXMg YmV0d2VlbiB0aGUgdHdvIHNpZGVzICh0byBhbGxvdyBib3RoIHNpZGVzIHRvIGtub3cgd2hldGhl ciBvciBub3Qgd2UncmUgdXNpbmcgYSBQUEspOyB0aGUgb2J2aW91cyBtZW50aW9uIHdvdWxkIGJl IGlmIHRoZSBub3RpZmllcyBpbmNsdWRlZCBQUkYoIFBQSywgImZpeGVkIHZhbHVlIiApLg0KDQpB cyBmb3IgYW4gT3JhY2xlLCBJIGRvbid0IGJlbGlldmUgdGhhdCB3b3VsZCBwcmVzZW50IGEgcHJv YmxlbTsgdGhlIGdlbmVyYWwgYXNzdW1wdGlvbiBpcyB0aGF0IFBQS3MgaGF2ZSBlbm91Z2ggZW50 cm9weSB0byBiZSBjb21wbGV0ZWx5IHVuZ3Vlc3NhYmxlIChhbmQgaWYgdGhhdCdzIGFzc3VtcHRp b24gaXMgd3JvbmcsIHRoaXMgZG9lc27igJl0IG1ha2UgaXQgYW55IHdvcnNlKS4gIEluIGFueSBj YXNlOg0KCS0gV2l0aCB0aGUgY3VycmVudCBwcm90b2NvbCwgYW4gYWN0aXZlIGF0dGFja2VyIGNh biBhbHJlYWR5IGRldGVybWluZSB3aGV0aGVyIGEgZ3Vlc3Mgb2YgdGhlIFBQSyBpcyBjb3JyZWN0 IChhc3N1bWluZyB0aGV5J3JlIHRoZSBzaWRlIHRoYXQgZmlyc3QgcmVjZWl2ZXMgYW4gZW5jcnlw dGVkIG1lc3NhZ2UgYWZ0ZXIgd2Ugc3RpciBpbiB0aGUgUFBLLCBpdCBjYW4gb2J2aW91c2x5IHRy eSBkaWZmZXJlbnQgUFBLcyB0byBzZWUgd2hpY2ggb25lIGFsbG93cyBhIHBsYXVzaWJsZSBkZWNy eXB0aW9uKS4NCgktIFdpdGggdGhpcyBwcm90b2NvbCBleHRlbnNpb24sIGEgcGFzc2l2ZSBhdHRh Y2tlciBjb3VsZCBwbGF1c2libHkgZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIGNvbm5lY3Rpb24gZmFp bGVkIGR1ZSB0byBhIFBQSyBtaXNtYXRjaCBvciBzb21ldGhpbmcgZWxzZSAocHJlc3VtYWJseSwg dGhlIGltcGxlbWVudGF0aW9uIHdpbGwgcmVhY3QgZGlmZmVyZW50bHkgZHVlIHRvIHRoZSB0d28g ZXJyb3IgbW9kZXMpLiAgSXQncyBub3QgYXQgY2xlYXIgd2hldGhlciB0aGF0IGxlYWtzIGFueSBp bnRlcmVzdGluZyBpbmZvcm1hdGlvbjsgdGhlIG9ubHkgd2F5IHRoYXQgYW4gYXR0YWNrZXIgY291 bGQgaW5kdWNlIGEgUFBLIG1pc21hdGNoIG9uIHByb3Blcmx5IGNvbmZpZ3VyZWQgc3lzdGVtcyBp cyBieSBtZXNzaW5nIHdpdGggdGhlIElEIHBheWxvYWRzIChQUEtzIGFyZSBzZWxlY3RlZCBiYXNl ZCBvbiB0aGUgSUQgcGF5bG9hZHMpLCBhbmQgb25lIHdvdWxkIGhvcGUgc3VjaCBhIG1vZGlmaWNh dGlvbiB3b3VsZCBjYXVzZSBhIGZhaWx1cmUgZWFybGllci4NCg0KU28sIHdoYXQgZG9lcyB0aGUg V0cgdGhpbms/ICBXb3VsZCBkb2luZyBzb21ldGhpbmcgbGlrZSB0aGlzICh0byBhbGxvdyBib3Ro IHNpZGVzIHRvIGRldGVybWluZSBhIFBQSyBtaXNtYXRjaCB2cy4gc29tZSBvdGhlciBmYWlsdXJl KSBiZSBpbXBvcnRhbnQ/ICBXb3VsZCB0aGUgaW5mb3JtYXRpb25hbCBsZWFrYWdlIGJlIGEgY29u Y2Vybj8NCg0KDQoNCg== From nobody Tue Jan 10 18:52: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 EACE1129887 for ; Tue, 10 Jan 2017 18:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 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=-3.199] 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 EOw7Sb_-lXXn for ; Tue, 10 Jan 2017 18:52:42 -0800 (PST) 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 18496126FDC for ; Tue, 10 Jan 2017 18:52:42 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tytjM4wKMz8b; Wed, 11 Jan 2017 03:52:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1484103159; bh=IQa5RqVYeyoi68HVJXvf0hmNJydqbR3fQiEytoHgkaI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=F7DCtoXlS3387ofVz0RLzmuWrD7NCTK+STBZysNSfv7v/sxQ4te125vSxf7aNfc5/ 2LKF55uovfxY/rKrMPEPeEWjmGF9hSoeTLa4KiR4eu5qJCGjbyk2vNbZVAAu76iCen /u1YQ25tIIs7Xpi7R7FKTtC97a5lSMBI7unUFDmk= 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 55qTJ4pPooDc; Wed, 11 Jan 2017 03:52:38 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 11 Jan 2017 03:52:38 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D79266ED5B1; Tue, 10 Jan 2017 21:52:35 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca D79266ED5B1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BD6E740D7281; Tue, 10 Jan 2017 21:52:35 -0500 (EST) Date: Tue, 10 Jan 2017 21:52:35 -0500 (EST) From: Paul Wouters To: "Scott Fluhrer (sfluhrer)" In-Reply-To: <68d87dd3d4974691b9e21294601014d7@XCH-RTP-006.cisco.com> Message-ID: References: <8194C08F-F2F9-4B2E-B061-A02106969884@vigilsec.com> <22629.2793.418553.140726@fireball.acr.fi> <7633.1483030288@obiwan.sandelman.ca> <68d87dd3d4974691b9e21294601014d7@XCH-RTP-006.cisco.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IETF IPsec Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 02:52:43 -0000 On Tue, 10 Jan 2017, Scott Fluhrer (sfluhrer) wrote: >> Would it be reasonable to create some token/nonce from something before >> the PPK is mixed in such that we could recognize the different AUTH >> FAILUREs, or does that create too much of an oracle for testing PPKs? > > I believe that would be reasonable. We already exchange notifies between the two sides (to allow both sides to know whether or not we're using a PPK); the obvious mention would be if the notifies included PRF( PPK, "fixed value" ). I would prefer that we do not signal different AUTH failures in a way that tells them which part of the AUTH process they got wrong. Paul From nobody Tue Jan 10 21:25: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 A3DBF12998C for ; Tue, 10 Jan 2017 21:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dkjUs4WLZcf for ; Tue, 10 Jan 2017 21:25:20 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0132.outbound.protection.outlook.com [23.103.201.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B109129988 for ; Tue, 10 Jan 2017 21:25:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KxaABWUv+olGSA4DVPt0HOY/0/7W1ai2Z+EBqFCk5T0=; b=AnCskfK3XTcCQgqgi6hR9y2hkENlqkkwBk+WF80b6LmtLgUTvFDozkBtldZb3paHK895d4yg8JByb7lVaqC8mHIzKJpTi+H4VEHNp4b6S7q3n879DS5yL1HfoPGEsk5IqpRwO4MbTXLjoQOATP6Wmfsr+AXwboS35mw3jAHkz/E= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1439.namprd09.prod.outlook.com (10.173.50.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Wed, 11 Jan 2017 05:25:17 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0845.012; Wed, 11 Jan 2017 05:25:17 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: WGLC on draft-ietf-ipsecme-rfc7321bis-01 Thread-Index: AdJrywm/WRDK3gzmTFakgqCJ3Ze8yQ== Date: Wed, 11 Jan 2017 05:25:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.218.147] x-ms-office365-filtering-correlation-id: e84bfa6a-4662-4d06-89de-08d439e23ac9 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR09MB1439; x-microsoft-exchange-diagnostics: 1; MWHPR09MB1439; 7:EEDv5GDuYEqOmtppBnUX2f6VlYq0hLjIhbSdmuNyT1n/CbodbsXgtkO6Cgaj6ufiRl/gIMnpmsmdpvqP+d6EvRQRlRTdwZwcTLJm+c0HAnICKLUrsagzSVSxloCzPBtGCFnsyyiaS2bx6FkK+KNv6+mPp/J534aJhpC0Ha3F37Yx2GQ2i7L/APSW6PMRJM8/bnIOAYAIDWxni4kjBjhRlH9ly5t6Pl8VKhxfSvGwi/08DKPMdM+WzvVD+pGV2xKXge0yPbS28qzRKkrjiBikPVG4m+EKtUN/Fmc/ZuVDmQBa+24qfrvtc2Su0HHVTgBmUUiAsNb5Q8ScWakHpZ2/aRM8N0LA6tYamXdD39/mGwW3c2ETZ7zeuBCRqKUrvaAN/6cGAWpJvgFlwnAAjFrmLqa2Brjx+jDtmmdKbI1o7we2y+J4KQGa1pyUiaKvIZsrNLoRIMVwRdf/q1bC7VN9zA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:MWHPR09MB1439; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1439; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39450400003)(39840400002)(39410400002)(39850400002)(199003)(189002)(68736007)(8936002)(81156014)(33656002)(110136003)(81166006)(189998001)(7736002)(97736004)(50986999)(7696004)(54356999)(107886002)(8676002)(66066001)(305945005)(101416001)(5660300001)(6116002)(6506006)(6436002)(102836003)(3846002)(77096006)(25786008)(3660700001)(38730400001)(122556002)(55016002)(106356001)(99286003)(105586002)(6916009)(74316002)(3280700002)(6306002)(450100001)(230783001)(86362001)(2906002)(92566002)(9686003)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1439; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2017 05:25:17.5789 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1439 Archived-At: Subject: [IPsec] WGLC on draft-ietf-ipsecme-rfc7321bis-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 05:25:22 -0000 All, This message starts a Working Group Last Call (WGLC) for draft-ietf-ipsecme= -rfc7321bis-01. The version to be reviewed is https://www.ietf.org/id/draft-ietf-ipsecme-rf= c7321bis-01.txt. Please send your comments, questions, and edit proposals to the WG mail lis= t until January 20th, 2017. If you believe that the document is ready to b= e submitted to the IESG for consideration as a Standards Track RFC please s= end a short message stating this. Best Regards, Dave and Tero From nobody Wed Jan 11 06:06: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 46C99129EB1 for ; Wed, 11 Jan 2017 06:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 lRVoJBObFJ-F for ; Wed, 11 Jan 2017 06:06:25 -0800 (PST) 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 E7981129C66 for ; Wed, 11 Jan 2017 06:06:24 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DE1B420567 for ; Wed, 11 Jan 2017 09:25:51 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 56DDE636BB for ; Wed, 11 Jan 2017 09:06:23 -0500 (EST) From: Michael Richardson To: IETF IPsec In-Reply-To: References: <8194C08F-F2F9-4B2E-B061-A02106969884@vigilsec.com> <22629.2793.418553.140726@fireball.acr.fi> <7633.1483030288@obiwan.sandelman.ca> <68d87dd3d4974691b9e21294601014d7@XCH-RTP-006.cisco.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] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 14:06:31 -0000 --=-=-= Content-Type: text/plain Paul Wouters wrote: >>> Would it be reasonable to create some token/nonce from something >>> before the PPK is mixed in such that we could recognize the different >>> AUTH FAILUREs, or does that create too much of an oracle for testing >>> PPKs? >> I believe that would be reasonable. We already exchange notifies >> between the two sides (to allow both sides to know whether or not >> we're using a PPK); the obvious mention would be if the notifies >> included PRF( PPK, "fixed value" ). > I would prefer that we do not signal different AUTH failures in a way > that tells them which part of the AUTH process they got wrong. The use of PRF(PPK,"X") does not place that signal on the wire, but permits that signal to be in the log. Scott: how do you think PPKs will get entered initially (i.e. until we have some quantum-resistant mechanism to distribute them)? Humans typing them in, QR codes scanned, USB keys sent via Fedex? If we are serious about this, then it matters. If Humans is the answer, then I would like to suggest the document suggest a standard humen presentation format, such as bubble-babble [first hit: http://www.wisegeek.com/what-is-bubble-babble.htm. Maybe there is a better reference]. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlh2O94ACgkQgItw+93Q 3WXkcgf/ZKN3gZiKy2W3+8xrZ/Vnf2t16zeAqD7brBqIXhChKnHiKgTCMqLyLTcr uw4VljNXkFuRTiXWnPgaek64xnpDZOBMt+u4/72vlgeod9ZxcfrpNYYQ+A6+ai92 CQXWReIkD1hyzfc18d8/gBXBu04se3OtXzsGz1AjEjF71OpDDJKIXBljxFS5ysy0 ov2pDPHhXg2ckV+YasUJgEvyjU0Oq17jB3pS7xbvbRfsVQo2Z1yyIu+PBaO3ix6X oeeaZX+WT0tHWqCceKAstHmB3OOikjpQSBXh0eViUGWY+lim+RAEoxsUAeTzbA7o 4CSDUU08yfHcyQueVCAJhTaZPAs+sw== =rb+C -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 11 06:07: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 E4F35129EBF for ; Wed, 11 Jan 2017 06:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 q1ej0M1-RZ3A for ; Wed, 11 Jan 2017 06:07:52 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC73129EBE for ; Wed, 11 Jan 2017 06:07:52 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id BBFF420567 for ; Wed, 11 Jan 2017 09:27:19 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3265A636BB for ; Wed, 11 Jan 2017 09:07:51 -0500 (EST) From: Michael Richardson To: IETF IPsec In-Reply-To: <68d87dd3d4974691b9e21294601014d7@XCH-RTP-006.cisco.com> References: <8194C08F-F2F9-4B2E-B061-A02106969884@vigilsec.com> <22629.2793.418553.140726@fireball.acr.fi> <7633.1483030288@obiwan.sandelman.ca> <68d87dd3d4974691b9e21294601014d7@XCH-RTP-006.cisco.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] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 14:07:57 -0000 --=-=-= Content-Type: text/plain I found this: http://wiki.yak.net/589/Bubble_Babble_Encoding.txt probably never progressed into the IETF? Or maybe it's an RFC already :-) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlh2PDYACgkQgItw+93Q 3WU6Iwf/V4bSHX9fobKm6OV8+97MuY+mDppMQmV5D+MoPmL20zeAHs5TwoOzh8YK Bye/eytVJpjo8v0g4STJRKXcp3fK+dIge5FTk5Yd2O53vxEg5mxcAWw8OKFCpurh rZU9hlsDD1OtNhi92HjFgnN9Zoc+GfmFiYOGTQpbuAftDAmtJ4PCdniA4xzTCKKe wiYr1aFOoe9oWPyS4gIdugK8aSC1t4ep83+VbUkUfKaXN17lbwR6od6azVqLl7BO 1L6N4BeZlzTHZlQIq0c45vBngt8hijG2Du19ZhQ464gcM5/SWfwU48RtL9Rtks5I nzLlfmtveyLI+sYe9KsVBHxm96p02A== =ccES -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 11 07:04:10 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 505C61294FA for ; Wed, 11 Jan 2017 07:04:09 -0800 (PST) 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 K2Ja2mST5YQA for ; Wed, 11 Jan 2017 07:04:07 -0800 (PST) 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 C1F131293FB for ; Wed, 11 Jan 2017 07:04:06 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v0BF42AO011764 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 11 Jan 2017 17:04:02 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v0BF42s5001766; Wed, 11 Jan 2017 17:04:02 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22646.18786.629023.688752@fireball.acr.fi> Date: Wed, 11 Jan 2017 17:04:02 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 80 min X-Total-Time: 60 min Archived-At: Subject: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 15:04:09 -0000 This draft should be quite ready for the WGLC, so I will start that shortly, but here are comments from my chair review of the draft. Consider these comments just like any WGLC comments. -- In section 6, there is text saying: In order to close an IKE session, either the initiator or responder SHOULD gracefully tear down IKE SAs with DELETE payloads. Once all SAs have been deleted, the initiator of the original connection MUST close the TCP connection. I do not understand the reasoning behind the MUST, or actually also whether it is that it MUST be initiator of the original connection closing, it or that connection MUST be closed after all SAs are deleted. If it is supposed to say that once all SAs are deleted the connection MUST be deleted, then it does not really matter who will close it, as once all SAs are gone, there cannot be any new IKE exchanges on the TCP connection. If it is trying to say that only original initiator can close the connection, just in case it wants to reuse it for new IKE INIT message, then the text needs to change to say that. I.e., what is this MUST trying to say? -- The streams of data sent over any TCP connection used for this protocol MUST begin with the stream prefix value followed by a complete message, which is either an encapsulated IKE or ESP message. ... I think this should be rephrased in a way that when initiator creates new TCP connection, it MUST send the stream prefix value first, followed by a IKE or ESP message. The responder might receive them in pieces, because of the TCP, so responder should not consider it an error to only receive stream prefix and parts of the first message. If it sees partial message it should wait for the rest of the message to come or untile timeout occurs. Note, the responder do need timeout in this case, as we do want to clean up the state if we have partial messages in the TCP stream, even when the TCP connection itself is not broken. -- If the connection is being used to resume a previous IKE session, the responder can recognize the session using either the IKE SPI from an encapsulated IKE message or the ESP SPI from an encapsulated ESP message. There should be note here and later explaining that this IKE or ESP message must pass authentication checks, and MUST be fresh. I.e., replaying old IKE or ESP message over tcp stream must not move traffic to new TCP connection. This text here tells which IKE it belongs, but later three is text saying: It should choose the TCP connection on which it last received a valid and decryptable IKE or ESP message. so that should also include note, that messages must be fresh. Note, that definition of fresh is not obvious. For the ESP it is not enough that it is unseen message in the replay window, as the replay window might be quite large, and acquiring ESP message not seen by the other end is quite possible. I think it is best to require that the ESP message must be with higher sequence number ever seen before... This should be happening anyways, as there will not be reordering happening inside the TCP connection, so this will not cause issues for normal cases. Same for the IKE SA, i.e. the message-id must be larger than anything seen before, not just something that is in the window. Also why this text has only lowercase "should", not uppercase MUST? -- If either initiator or responder receives a stream that cannot be parsed correctly, it MUST close the TCP connection. I think this needs more text. I.e., if it receives random garbage, then it must close the TCP connection. But if it receives authenticated IKEv2 message, which passes IKE SA message authentication, but which is cannot be parsed correctly (i.e., result in the INVALID_SYNTAX error), then it will return INVALID_SYNTAX error, tear down the IKE SA (as specified in the RFC7296) and close the TCP connection. -- Multiple IKE SAs SHOULD NOT share a single TCP connection. I think this needs to be MUST NOT. I mean if we assume that the first IKE or ESP message coming from the newly formed TCP connection tells which IKE SA this TCP connection belongs, we cannot really use one TCP connection for multiple IKE SAs. Of course we should allow IKE SA rekeying over the same TCP connection, but I think that is only exception to the multiple IKE SAs using same TCP connection, and in that case the one end will delete the old rekeyed IKE SA soon. So I would change that to MUST, and add note about rekeying case. -- In section 7 we should also mention that the fact whether there is NAT or not in the path can affect the TCP and UPD packet checksum fixup for transport mode traffic (RFC7296 section 2.23.1). -- In section 8, there is text: When an IKE session is transitioned between networks using MOBIKE [RFC4555], the initiator of the transition may switch between using MOBIKE is not property of the networks, it is property of the implementations. I.e., change this to say "When an IKE session is created between implementations using MOBIKE, ..." -- In section 9: fragmentation. Even if fragmentation is negotiated, an implementation MAY choose to not fragment when going over a TCP connection. why allow fragmentation over TCP connection? I think we could say that fragmentation SHOULD NOT be used when sending messages over TCP connection? The only reason I can think why someone would use fragmentation is that they are using mobike and the initiator is using UDP and tries to send some large message which requires fragmentation on UDP first, and then when the packets do not get through it tries to move to use TCP, and in that case it MUST forward the IKE packet just as it was sent over the UDP to the TCP, so the packet will have fragmentation headers in it. So I would say MUST accept packets with fragmentation from TCP if fragmentation is supported and enabled. SHOULD NOT fragment packets if sending them to the TCP connection. -- In the security considerations section we should also mention that attackers can do quite a lot of same tricks explained in the MOBIKE [RFC4555] security considerations. Perhaps put pointer to there, and think that list through and list which of those can be done also when using TCP connection. The TCP connection has same kind of properties than MOBIKE, as it will allow changing the source IP and port of the incoming connection, and SGW will update its mapping to match the latest connection... -- In section B.1, the IKE messages should have "Non-ESP Marker" visible on the figure 4. -- In section B.3, there should be the one mandatory IKE or ESP packet after the "IKETCP" stream prefix. Perhaps use ESP here as example... -- In section B.4 step 6 should note, that this message in step 6, is actually retransmission of the message sent in step 2, i.e., it is exactly same IKE message including message-id and the contents. -- kivinen@iki.fi From nobody Wed Jan 11 07:24:10 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 906891294A4 for ; Wed, 11 Jan 2017 07:24:09 -0800 (PST) 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 e0iJHremudO2 for ; Wed, 11 Jan 2017 07:24:08 -0800 (PST) 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 35DBD12948C for ; Wed, 11 Jan 2017 07:24:08 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v0BFO62j027766 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 11 Jan 2017 17:24:06 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v0BFO5xY024407; Wed, 11 Jan 2017 17:24:05 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22646.19989.880724.288006@fireball.acr.fi> Date: Wed, 11 Jan 2017 17:24:05 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 4 min Archived-At: Subject: [IPsec] Working group last call for the draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 15:24:09 -0000 This message will start two week working group last call for the draft-ietf-ipsecme-tcp-encaps-04 [1] draft. Please send your comments, questions etc to WG mailing list before 2017-01-29. If you belive that the document is ready to be submitted to the IESG for consideration as a standard track RFC please send a short message stating this also. [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ -- kivinen@iki.fi From nobody Wed Jan 11 14:27: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 362EA1295C1 for ; Wed, 11 Jan 2017 14:27:01 -0800 (PST) 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, HTML_MESSAGE=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 (1024-bit key) header.d=iol.unh.edu 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 GnOM2R51XOoG for ; Wed, 11 Jan 2017 14:26:58 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 2641A1295B2 for ; Wed, 11 Jan 2017 14:26:58 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id y9so1510720uae.2 for ; Wed, 11 Jan 2017 14:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:from:date:message-id:subject:to; bh=xrINWqcIiWAzO/EbSbut3/NBAnJYVga4IaReInGlkas=; b=BZGyeOB3g9eQLax+XlfdKJs0S1YETvvDpqjigftyjmqfB2s714gtckJLUg07lOsG+U 6BsTdWYx4k+/W11cN6FFzXplyPTEOSOR4f02y8G0Loa1w7ZaasMqdBS2z6mmzJL9J8VQ P3baDd4MxPsnjD5J5iaUecV0i9x58sIjm9FBY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xrINWqcIiWAzO/EbSbut3/NBAnJYVga4IaReInGlkas=; b=ICl0wMeL3btp8V33ZKzUS8DtSvljdGn3ff1UCDwPW2ofD7jpEMlUebqfHVOJVA0WS9 T/hrI9v6WJ+FiMufiE18XHOeaHN0Lw6y6BrRblDpqvWchdfJ853IEvskKnMOrBf40+k1 3pAA1qJMIB7opTxknjQT06PrOBOZFW40pMXC6dT7tdRCKeYaWB6vlV+vYbRzQ0yayTiL /e1OFlQ+Bc4hk5wVKcnHnkK93OIeOGiL6jEqTuwx1+wNsS5HeJ95Z4BQQksVGYeeKB97 J4ly2CXLPqXtaPYQSB6TJzGe7VJRrceqxrHrg3YLaGdVxNB/iunytpDuH3nEDijzFaOX 80Yg== X-Gm-Message-State: AIkVDXJ5NlOKFsoETQXjTyeAheeUBB+/PeJ0DYORfkVGwSuwT+Qy7sJPv/AnLxwLrUAHD3YMmqMOA05vpGjnUtGj X-Received: by 10.176.84.210 with SMTP id q18mr6113127uaa.35.1484173616840; Wed, 11 Jan 2017 14:26:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.36.184 with HTTP; Wed, 11 Jan 2017 14:26:16 -0800 (PST) From: Timothy Carlin Date: Wed, 11 Jan 2017 17:26:16 -0500 Message-ID: To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=f403045e22223850d20545d9198d Archived-At: Subject: [IPsec] Review of draft-ietf-ipsecme-rfc7321bis-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 22:27:01 -0000 --f403045e22223850d20545d9198d Content-Type: text/plain; charset=UTF-8 Hello All, I have reviewed this draft and have a couple of comments and small text nits below as a diff. The addition of Section 3 regarding Manual Keying is good for providing guidance for compliance testing programs and ultimately to strongly discourage its use. My comments: * Section 4 mentions that that 256-bit keys are raised to the SHOULD level. Should this read as these are now the MUST level as ENCR_AES_CBC and ENCR_AES_GCM_16 are at the MUST level according to Table 1 (with the [1] endnote)? * Section 5 mentions ENCR_NULL_AUTH_AES_GMAC, which is not referenced anywhere in the document. Should it be added to Table 1 at the MUST level? Tim Carlin UNH-IOL ============================================== --- draft-ietf-ipsecme-rfc7321bis-01.txt 2017-01-08 14:19:52.000000000 -0500 +++ draft-ietf-ipsecme-rfc7321bis-01-carlin-review.txt 2017-01-11 17:06:09.000000000 -0500 @@ -118,7 +118,7 @@ The field of cryptography evolves continuously. New stronger algorithms appear and existing algorithms are found to be less secure - then originally thought. Therefore, algorithm implementation + than originally thought. Therefore, algorithm implementation requirements and usage guidance need to be updated from time to time to reflect the new reality. The choices for algorithms must be conservative to minimize the risk of algorithm compromise. @@ -143,7 +143,7 @@ completely broken before this document is updated. This document only provides recommendations for the mandatory-to- - implement algorithms or algorithms too weak that are recommended not + implement algorithms and algorithms too weak that are recommended not to be implemented. As a result, any algorithm listed at the IPsec IANA registry not mentioned in this document MAY be implemented. As [RFC7321] omitted most of the algorithms mentioned by the IPsec IANA @@ -241,7 +241,7 @@ 3. Manual Keying - Manual Keying is not be used as it is inherently dangerous. Without + Manual Keying is not to be used as it is inherently dangerous. Without any keying protocol, it does not offer Perfect Forward Secrecy ("PFS") protection. Deployments tend to never be reconfigured with fresh session keys. It also fails to scale and keeping SPI's unique @@ -269,6 +269,7 @@ | ENCR_AES_CCM_8 | SHOULD | Yes | [RFC4309]IoT] | | ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] | | ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] | + | ENCR_NULL_AUTH_AES_GMAC | MUST | Yes | [RFC4543][1] | +-------------------------+------------+---------+---------------+ @@ -291,9 +292,12 @@ IPsec sessions may have very long life time, and carry multiple packets, so there is a need to move 256-bit keys in the long term. - For that purpose requirement level is for 128 bit keys and 256 bit - keys are at SHOULD (when applicable). In that sense 256 bit keys - status has been raised from MAY in RFC7321 to SHOULD. + For that purpose the requirement level for 128 bit keys and 256 bit + keys is MUST (when applicable). In that sense 256 bit keys + * status has been raised from MAY in RFC7321 to MUST. + * [TJC Comment - ENCR_AES_CBC, ENCR_AES_GCM_16, and ENCR_NULL_AUTH_AES_GMAC, + each have 128 and 256 bit key sizes at the MUST level, according to + Table 1 above] IANA has allocated codes for cryptographic algorithms that have not been specified by the IETF. Such algorithms are noted as @@ -319,7 +323,7 @@ ENCR_BLOWFISH has been downgraded to MUST NOT as it has been deprecated for years by TWOFISH, which is not standarized for ESP and - therefor not listed in this document. Some implementations support + therefore not listed in this document. Some implementations support TWOFISH using a private range number. ENCR_NULL status was set to MUST in [RFC7321] and remains a MUST to @@ -327,9 +331,9 @@ over AH due to NAT traversal. ENCR_NULL is expected to remain MUST by protocol requirements. - ENCR_AES_CBC status remains to MUST. ENCR_AES_CBC MUST be + ENCR_AES_CBC status remains as MUST. ENCR_AES_CBC MUST be implemented in order to enable interoperability between - implementation that followed RFC7321. However, there is a trend for + implementations that followed RFC7321. However, there is a trend for @@ -402,9 +406,9 @@ AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The only reason NULL is acceptable is when authenticated encryption - algorithms are selected from Section 4. In all other case, NULL MUST - NOT be selected. As ESP and AH provides both authentication, one may - be tempted to combine these protocol to provide authentication. As + algorithms are selected from Section 4. In all other cases, NULL MUST + NOT be selected. As ESP and AH both provide authentication, one may + be tempted to combine these protocols to provide authentication. As mentioned by RFC7321, it is NOT RECOMMENDED to use ESP with NULL authentication - with non authenticated encryption - in conjunction with AH; some configurations of this combination of services have @@ -421,18 +425,20 @@ AUTH_DES_MAC was not mentioned in RFC7321. As DES is known to be vulnerable, it MUST NOT be used. - AUTH_AES_XCBC_96 is only recommended in the scope of IoT, as Internet - of Things deployments tend to prefer AES based HMAC functions in - order to avoid implementing SHA2. For the wide VPN deployment, as it - has not been widely adopted, it has been downgraded from SHOULD to + AUTH_AES_XCBC_96 status is set as SHOULD only in the scope of IoT, + as Internet of Things deployments tend to prefer AES based HMAC functions + in order to avoid implementing SHA2. For the wide VPN deployment, as it + has not been widely adopted, it is downgraded from SHOULD to MAY. AUTH_AES_128_GMAC status has been downgraded from SHOULD+ to MAY. Along with AUTH_AES_192_GMAC and AUTH_AES_256_GMAC, these algorithms - should only be used for AH not for ESP. If using ENCR_NULL, - AUTH_HMAC_SHA2_256_128 is recommended for integrity. If using GMAC - without authentication, ENCR_NULL_AUTH_AES_GMAC is recommended. + should only be used for AH and not for ESP. If using ENCR_NULL, + AUTH_HMAC_SHA2_256_128 is recommended for integrity. If using AES-GMAC + in ESP without confidentiality, ENCR_NULL_AUTH_AES_GMAC is recommended. Therefore, these ciphers are kept at MAY. + * [TJC Comment - ENCR_NULL_AUTH_AES_GMAC did not appear in this document, + I added it to Table 1.] AUTH_HMAC_SHA2_256_128 was not mentioned in RFC7321, as no SHA2 based authentication was mentioned. AUTH_HMAC_SHA2_256_128 MUST be --f403045e22223850d20545d9198d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All,

I have reviewed this draft a= nd have a couple of comments and small text nits below as a diff.

The addition of Section 3 regarding Manual Keying is good f= or providing guidance for compliance testing programs and ultimately to str= ongly discourage its use.

My comments:
<= br>
* Section 4 mentions that that 256-bit keys are raised to the= SHOULD level.=C2=A0 Should this read as these are now the MUST level as EN= CR_AES_CBC and ENCR_AES_GCM_16 are at the MUST level according to Table 1 (= with the [1] endnote)?

* Section 5 mentions ENCR_N= ULL_AUTH_AES_GMAC, which is not referenced anywhere in the document.=C2=A0 = Should it be added to Table 1 at the MUST level?

T= im Carlin
UNH-IOL

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- draft-ie= tf-ipsecme-rfc7321bis-01.txt 2017-01-08 14:19:52.000000000 -0500
+++ d= raft-ietf-ipsecme-rfc7321bis-01-carlin-review.txt 2017-01-11 17:06:09.000000000 = -0500
@@ -118,7 +118,7 @@
=C2=A0
=C2=A0 =C2= =A0 The field of cryptography evolves continuously.=C2=A0 New stronger
=C2=A0 =C2=A0 algorithms appear and existing algorithms are found to = be less secure
- =C2=A0 then originally thought.=C2=A0 Therefore,= algorithm implementation
+ =C2=A0 than originally thought.=C2=A0= Therefore, algorithm implementation
=C2=A0 =C2=A0 requirements a= nd usage guidance need to be updated from time to time
=C2=A0 =C2= =A0 to reflect the new reality.=C2=A0 The choices for algorithms must be
=C2=A0 =C2=A0 conservative to minimize the risk of algorithm compro= mise.
@@ -143,7 +143,7 @@
=C2=A0 =C2=A0 completely brok= en before this document is updated.
=C2=A0
=C2=A0 =C2= =A0 This document only provides recommendations for the mandatory-to-
=
- =C2=A0 implement algorithms or algorithms too weak that are recommen= ded not
+ =C2=A0 implement algorithms and algorithms too weak tha= t are recommended not
=C2=A0 =C2=A0 to be implemented.=C2=A0 As a= result, any algorithm listed at the IPsec
=C2=A0 =C2=A0 IANA reg= istry not mentioned in this document MAY be implemented.=C2=A0 As
=C2=A0 =C2=A0 [RFC7321] omitted most of the algorithms mentioned by the IP= sec IANA
@@ -241,7 +241,7 @@
=C2=A0
=C2=A03.= =C2=A0 Manual Keying
=C2=A0
- =C2=A0 Manual Keying is n= ot be used as it is inherently dangerous.=C2=A0 Without
+ =C2=A0 = Manual Keying is not to be used as it is inherently dangerous.=C2=A0 Withou= t
=C2=A0 =C2=A0 any keying protocol, it does not offer Perfect Fo= rward Secrecy
=C2=A0 =C2=A0 ("PFS") protection.=C2=A0 D= eployments tend to never be reconfigured with
=C2=A0 =C2=A0 fresh= session keys.=C2=A0 It also fails to scale and keeping SPI's unique
@@ -269,6 +269,7 @@
=C2=A0 =C2=A0 =C2=A0| ENCR_AES_CCM_8 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| SHOULD =C2=A0 =C2=A0 | Yes =C2=A0 =C2= =A0 | [RFC4309]IoT] |
=C2=A0 =C2=A0 =C2=A0| ENCR_AES_GCM_16 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | MUST =C2=A0 =C2=A0 =C2=A0 | Yes =C2=A0 =C2=A0 | = [RFC4106][1] =C2=A0|
=C2=A0 =C2=A0 =C2=A0| ENCR_CHACHA20_POLY1305= =C2=A0| SHOULD =C2=A0 =C2=A0 | Yes =C2=A0 =C2=A0 | [RFC7634] =C2=A0 =C2=A0= |
+ =C2=A0 =C2=A0| ENCR_NULL_AUTH_AES_GMAC | MUST =C2=A0 =C2=A0 = =C2=A0 | Yes =C2=A0 =C2=A0 | [RFC4543][1] =C2=A0|
=C2=A0 =C2=A0 = =C2=A0+-------------------------+------------+---------+---------------+
=C2=A0
=C2=A0
@@ -291,9 +292,12 @@
= =C2=A0
=C2=A0 =C2=A0 IPsec sessions may have very long life time,= and carry multiple
=C2=A0 =C2=A0 packets, so there is a need to = move 256-bit keys in the long term.
- =C2=A0 For that purpose req= uirement level is for 128 bit keys and 256 bit
- =C2=A0 keys are = at SHOULD (when applicable).=C2=A0 In that sense 256 bit keys
- = =C2=A0 status has been raised from MAY in RFC7321 to SHOULD.
+ = =C2=A0 For that purpose the requirement level for 128 bit keys and 256 bit<= /div>
+ =C2=A0 keys is MUST (when applicable).=C2=A0 In that sense 256 = bit keys
+ =C2=A0 * status has been raised from MAY in RFC7321 to= MUST.
+ =C2=A0 * [TJC Comment - ENCR_AES_CBC, ENCR_AES_GCM_16, a= nd ENCR_NULL_AUTH_AES_GMAC,
+ =C2=A0 each have 128 and 256 bit key si= zes at the MUST level, according to
+ =C2=A0 Table 1 above]
=C2=A0
=C2=A0 =C2=A0 IANA has allocated codes for cryptographic = algorithms that have not
=C2=A0 =C2=A0 been specified by the IETF= .=C2=A0 Such algorithms are noted as
@@ -319,7 +323,7 @@
=C2=A0
=C2=A0 =C2=A0 ENCR_BLOWFISH has been downgraded to MUST = NOT as it has been
=C2=A0 =C2=A0 deprecated for years by TWOFISH,= which is not standarized for ESP and
- =C2=A0 therefor not liste= d in this document.=C2=A0 Some implementations support
+ =C2=A0 t= herefore not listed in this document.=C2=A0 Some implementations support
=C2=A0 =C2=A0 TWOFISH using a private range number.
=C2= =A0
=C2=A0 =C2=A0 ENCR_NULL status was set to MUST in [RFC7321] a= nd remains a MUST to
@@ -327,9 +331,9 @@
=C2=A0 =C2=A0 = over AH due to NAT traversal.=C2=A0 ENCR_NULL is expected to remain MUST
=C2=A0 =C2=A0 by protocol requirements.
=C2=A0
= - =C2=A0 ENCR_AES_CBC status remains to MUST.=C2=A0 ENCR_AES_CBC MUST be
+ =C2=A0 ENCR_AES_CBC status remains as MUST.=C2=A0 ENCR_AES_CBC MU= ST be
=C2=A0 =C2=A0 implemented in order to enable interoperabili= ty between
- =C2=A0 implementation that followed RFC7321.=C2=A0 H= owever, there is a trend for
+ =C2=A0 implementations that follow= ed RFC7321.=C2=A0 However, there is a trend for
=C2=A0
= =C2=A0
=C2=A0
@@ -402,9 +406,9 @@
=C2=A0
=C2=A0 =C2=A0 AUTH_NONE has been downgraded from MAY in RFC7321 to MU= ST NOT.=C2=A0 The
=C2=A0 =C2=A0 only reason NULL is acceptable is= when authenticated encryption
- =C2=A0 algorithms are selected f= rom Section 4.=C2=A0 In all other case, NULL MUST
- =C2=A0 NOT be= selected.=C2=A0 As ESP and AH provides both authentication, one may
<= div>- =C2=A0 be tempted to combine these protocol to provide authentication= .=C2=A0 As
+ =C2=A0 algorithms are selected from Section 4.=C2=A0= In all other cases, NULL MUST
+ =C2=A0 NOT be selected.=C2=A0 As= ESP and AH both provide authentication, one may
+ =C2=A0 be temp= ted to combine these protocols to provide authentication.=C2=A0 As
=C2=A0 =C2=A0 mentioned by RFC7321, it is NOT RECOMMENDED to use ESP with= NULL
=C2=A0 =C2=A0 authentication - with non authenticated encry= ption - in conjunction
=C2=A0 =C2=A0 with AH; some configurations= of this combination of services have
@@ -421,18 +425,20 @@
=
=C2=A0 =C2=A0 AUTH_DES_MAC was not mentioned in RFC7321.=C2=A0 As DES = is known to be
=C2=A0 =C2=A0 vulnerable, it MUST NOT be used.
=C2=A0
- =C2=A0 AUTH_AES_XCBC_96 is only recommended in th= e scope of IoT, as Internet
- =C2=A0 of Things deployments tend t= o prefer AES based HMAC functions in
- =C2=A0 order to avoid impl= ementing SHA2.=C2=A0 For the wide VPN deployment, as it
- =C2=A0 = has not been widely adopted, it has been downgraded from SHOULD to
+ =C2=A0 AUTH_AES_XCBC_96 status is set as SHOULD only in the scope of Io= T,=C2=A0
+ =C2=A0 as Internet of Things deployments tend to prefe= r AES based HMAC functions=C2=A0
+ =C2=A0 in order to avoid imple= menting SHA2.=C2=A0 For the wide VPN deployment, as it
+ =C2=A0 h= as not been widely adopted, it is downgraded from SHOULD to
=C2= =A0 =C2=A0 MAY.
=C2=A0
=C2=A0 =C2=A0 AUTH_AES_128_GMAC = status has been downgraded from SHOULD+ to MAY.
=C2=A0 =C2=A0 Alo= ng with AUTH_AES_192_GMAC and AUTH_AES_256_GMAC, these algorithms
- =C2=A0 should only be used for AH not for ESP.=C2=A0 If using ENCR_NULL,=
- =C2=A0 AUTH_HMAC_SHA2_256_128 is recommended for integrity.=C2= =A0 If using GMAC
- =C2=A0 without authentication, ENCR_NULL_AUTH= _AES_GMAC is recommended.
+ =C2=A0 should only be used for AH and= not for ESP.=C2=A0 If using ENCR_NULL,
+ =C2=A0 AUTH_HMAC_SHA2_2= 56_128 is recommended for integrity.=C2=A0 If using AES-GMAC=C2=A0
+ =C2=A0 in ESP without confidentiality, ENCR_NULL_AUTH_AES_GMAC is recom= mended.
=C2=A0 =C2=A0 Therefore, these ciphers are kept at MAY.
+ =C2=A0 * [TJC Comment - ENCR_NULL_AUTH_AES_GMAC did not appear i= n this document,
+ =C2=A0 I added it to Table 1.]
=C2=A0
=C2=A0 =C2=A0 AUTH_HMAC_SHA2_256_128 was not mentioned in RFC7321, = as no SHA2 based
=C2=A0 =C2=A0 authentication was mentioned.=C2= =A0 AUTH_HMAC_SHA2_256_128 MUST be

--f403045e22223850d20545d9198d-- From nobody Wed Jan 11 22: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 82DA5126D73 for ; Wed, 11 Jan 2017 22:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 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=3.599, 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 RG5gJAnRCOGs for ; Wed, 11 Jan 2017 22:50:26 -0800 (PST) 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 0CF5812948D for ; Wed, 11 Jan 2017 22:50:26 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id k86so6736977lfi.0 for ; Wed, 11 Jan 2017 22:50:25 -0800 (PST) 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=Ln4+APYB0wc8/o/1pB1RT78B0/gQAaBWJ30txNrJUYY=; b=QTLm4IK4260SryvVHSgtVez/WeYXo3fG3cGRYwYCxrHaA0BjLBZIDMN1eQsBmmtZ4m uLztuTqPrpjz+u6SrtnH06cabC8UUxbyNKcI0gLXzZUxH2PB0epcHE+LgI3O1wCViwfi cQLytVKBhxNtUFigJa1y2TSrWDWYzVpLMLnrlcx/8bydzsa+W5cOISq00btuZI9tF86c HZMHmIY0y1qyhdNIF0SHiLsAnHUQL65QCmgdh+pZ76btDcbhjqFzVQrOESdvAkgbvRIR ehJdPDw7L/9Y+WTe5XAuGtTeOBSQcyXMMbWNiKfbbd+kOS8uYfsjDA6xVw6eUeiNg+HQ V7uQ== 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=Ln4+APYB0wc8/o/1pB1RT78B0/gQAaBWJ30txNrJUYY=; b=hNbZW0sbBrsjFuBmDejkAVU62uoH4XhgN8RbLwej/zIbh5FRMq8+0P76+7pKvzXJtA 8b1Jqw8VPOR0A3W7PyH9DHABQhtP72zg95vm7MtIpk3rq0jc/qNPqEbem13V7TXWT7a0 pJ+rsIKYMWhcdJ/5hS/hhddph1sLmJzueHEKIPzAyDzipWXdw4LmXoTOmFcSl3Z24Ism BVyK6xaQQpgkw8q6LILM8Ke+k9AUdgEmy5y30Q2cRbMwvQj+P6iUOCL8LsHdXHkUuZx8 Hw1jdvP0rmdIKXVGcXnvZ++5AKn8yjLjmHtQuwHjru80I2JybyL8GtaDtXWHcSDkkQ05 eQIg== X-Gm-Message-State: AIkVDXLLsLqY4zR8d3H9ZlCOq0DH1kKpTEJVf+sSqoJWw83gQW6efUHrtYf0LZQiPGcmfQ== X-Received: by 10.25.74.196 with SMTP id x187mr3852932lfa.30.1484203824156; Wed, 11 Jan 2017 22:50:24 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id x75sm1999165lfi.16.2017.01.11.22.50.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 11 Jan 2017 22:50:23 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" References: <8843.1481154231@obiwan.sandelman.ca> <89B050BB-AAC4-4C4B-870E-02A33006643F@gmail.com> <008901d2512d$305b6580$91123080$@gmail.com> <22601.24119.100454.380354@fireball.acr.fi> <00a101d25157$48cbb500$da631f00$@gmail.com> <22629.1255.436519.295663@fireball.acr.fi> In-Reply-To: <22629.1255.436519.295663@fireball.acr.fi> Date: Thu, 12 Jan 2017 09:50:14 +0300 Message-ID: <001a01d26ca0$214a4b90$63dee2b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGf0y3ElAb1MY6fIaqsOC5fSHHzigJCwQTLAXo2HB0CWUj3FAHh1UorAqcfQhECdlB39aEw6kNw Content-Language: ru Archived-At: Cc: 'IPsecme WG' , 'Michael Richardson' , 'Yoav Nir' , "'Scott Fluhrer \(sfluhrer\)'" Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 06:50:27 -0000 Hi Tero, as far as I understand, this proposal is not tied up with QR problem and can be used independently. So I suggest not to mix it with the proposed QR solution in one document. Regards, Valery. > > Then what is the content of IDi and IDr in IKE_AUTH in this case? > > As I said the IDi would be ID_KEY_D with value of > \x1c747c060d209a223d1f9f51b0351b54. IDr would most likely be the > normal server side identity, as hiding server identity is usually not > useful as server must have static IP so clients can know where to > connect. > > If server side identity protection is also needed, then server side > IDr would also be similar pseudonym, but that would require server to > keep track of which IDr was given to which client, and pick suitable > IDr based on the IDi coming in. > > > > ID_KEY_ID \x1c747c060d209a223d1f9f51b0351b54, it looks it up from its > > > table and finds a mapping from there to kivinen@iki.fi. From then on > > > it uses kivinen@iki.fi as authenticated identifier, and verifies that > > > the raw public key, or shared key used to authenticate the user > > > actually matches the one configured to the kivinen@iki.fi. > > > > > > Using certificates in this case would leak out the identity anyways, > > > so they cannot be used, or at least transmitted over wire. Even if > > > using raw public keys, the actual public keys must not be sent over > > > wire, it needs to be taken from the configuration. > > > > > > > And the peers must also somehow prove their real identities, so AUTH > > > > payloads must also be included, and we end up with something like > > > > full IKE_AUTH exchange... > > > > > > This all is done in the server, i.e. instead of using the ID sent over > > > the wire, the server uses the ID sent over wire as handle to the > > > table, and fetches the real ID to be used for policy decisions and > > > authentication from the that table. > > > > Again, what role the usual authentication (in IKE_AUTH) and > > usual IKE Identities play in this scenario? > > They would play their normal role, i.e. they would be used to > authenticate the connection. The only difference is that the IDi on > the wire would not be the real identity but the a random pseudonym, > and that pseudonym is then used by the server to fetch the real > identity which would then be used for policy purposes. To provide full > identity protection, even the server should not use any long term > identity like kivinen@iki.fi, but instead just use some kind of user > id and map that user id to the actual policy. > > I.e., the lookup would go like follows: > > IDi = ID_KEY_ID \x1c747c060d209a223d1f9f51b0351b54 > > -> In server look that id from the known pseudonyms, find entry > saying: > > Pseudonym_ID = \x1c747c060d209a223d1f9f51b0351b54 > User_ID = KeyId(\x1234) > > -> Use User_ID to search PAD for entry to verify authentication and > find the related SPD > > Then when the user changes their pseudonym using the protocol defined > later the first list of known pseudonyms would be updated to say: > > Pseudonym_ID = \x056f32ee5cf49404607e368bd8d3f2af > User_ID = KeyId(\x1234) > > where the Pseudonym_ID is new random pseudonym to be used after that > for future exchanges. The User_ID stays same, but it is just internal > information inside the server, and is never transmitted over the wire. > Of course the User_ID could also be RFC822(kivinen@iki.fi) instead of > that kind of random number, but then hacking in to the server could > reveal the real user identities for the clients and their next > pseudonyms, so that would be bad idea if full protection is needed. > > Server does not really need to know who is in the other end, he just > needs to know how the other end is going to authenticate himself > (i.e., which PAD entry to use), and what kind of policy is allowed for > that user (i.e., which SPD entries are used). > -- > kivinen@iki.fi From nobody Wed Jan 11 23:01: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 44BB112944D for ; Wed, 11 Jan 2017 23:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 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=3.599, 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 gZeRrrbkxG1H for ; Wed, 11 Jan 2017 23:01:32 -0800 (PST) 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 1B9FF126D73 for ; Wed, 11 Jan 2017 23:01:32 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id v186so6862311lfa.1 for ; Wed, 11 Jan 2017 23:01:32 -0800 (PST) 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=jXzR901+Pw+CEBgGNqsZC7hEUF3uxy1vMe0kXtohvY4=; b=ZFJdEzVdar+RCvPCeaKb4KMz3rQ+1sU8MI5gO8t7oyz4AzcoNZMekihvcISCeVv7/S Ahi33oa81K9JO7iWy5+kdOiYF/Bt0RROu+gZR0fXMrdvkOpV0Yi9443HefExb4J4MCEA omOrtIBR4Q8cy/4U76KpHMKETKnKz2BEX+BIbc36JoNRU6pttRr0q4K0mTIOzd8APyxe lxUh+1H8e2WRWeLAP2NxET+jtUOtg4eVvv0GTFlX7fxv+g86waNghcv5oiJiS1fjjjcI 3Z2+Y9hk8VyPmSuFPwRWOdZkAuwW7M+KrFW3P934QODC2mrrek9wP63TLdmBf4JjDNKC 5A/Q== 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=jXzR901+Pw+CEBgGNqsZC7hEUF3uxy1vMe0kXtohvY4=; b=h48jt5p5XV2s51ctEbHO6R3Ro9AyEhZGzmpqyRuvprRhcfVI9DuTWUvrkaawHbVNVN W7JetP0ozxjOC641hKAPtG8wrGwcSgpLCdMXNG8zSJazG0beG6qmYVTm4uhdeCTR7JWT 28FBeLe+qDZSXEtdDuWVl4IBdhh6KLew/wvlzcNA4LUJmHd90NWbjocbdR1vXqP1k9nq nb18TMFgnICT6IwTzhNYdZV1tpJby2Oe90zwiBE9ETOtOSMBTvBOUD1SyuUQ4L+qFwPW u1t89gBpAm/J4zWKg5wUx1EVnuXkkjbg2igqlN73EOFMllDA07Jz8W+t9bDSQkp25IZa C/Xg== X-Gm-Message-State: AIkVDXKLvtdut8Hosms91fXGXZKP3Fys5c6IOXaVyE46PwHUuiayco47Nze/8+GD4R5RwA== X-Received: by 10.25.193.145 with SMTP id r139mr1012156lff.73.1484204490320; Wed, 11 Jan 2017 23:01:30 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id t23sm68865ljd.30.2017.01.11.23.01.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 11 Jan 2017 23:01:29 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" , "'Scott Fluhrer \(sfluhrer\)'" References: <8194C08F-F2F9-4B2E-B061-A02106969884@vigilsec.com> <22629.2793.418553.140726@fireball.acr.fi> In-Reply-To: <22629.2793.418553.140726@fireball.acr.fi> Date: Thu, 12 Jan 2017 10:01:21 +0300 Message-ID: <001b01d26ca1$ae614370$0b23ca50$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGf0y3ElAb1MY6fIaqsOC5fSHHzigGoWBMQAZex9aUBz07S36FxH18w Content-Language: ru Archived-At: Cc: 'IETF IPsec' Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 07:01:34 -0000 Hi again, > I would propose that we add PPK to both SK_d and SK_pi and SK_pr. > > SK_d provides quantum resistance for the IPsec SAs and Child IKE SAs. > The SK_pi and SK_pr provides key verification, meaning that incorrect > PPKs will result AUTHENTICATION_FAILURE notification, instead of just > wrong keys. > > SK_pi and SK_pr as used to MAC the ID payloads of the peers, and if we > mix PPK in there that might also provide some resistance against > quantum computers even when the attackers can break RSA. I.e., it does > not matter that they can generate valid signatures if they do not know > what they are supposed to sign. That will work. However, I'm not sure that a single AUTHENTICATION_FAILURE notification is a good thing from operational point of view. A separate notification indicated that PPKs are mismatched could be more preferred to quickly trace back and fix configuration errors. Regards, Valery. From nobody Wed Jan 11 23:44: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 89D111293E4 for ; Wed, 11 Jan 2017 23:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 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=3.599, 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 DH3V1A2Geiln for ; Wed, 11 Jan 2017 23:44:22 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 DC8181270B4 for ; Wed, 11 Jan 2017 23:44:21 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id m78so7397488lfg.2 for ; Wed, 11 Jan 2017 23:44:21 -0800 (PST) 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=zeLdtlm5fyG4e4NmZsB12NmZQsKiGBBJ/0OLv9txh08=; b=hdwJtJXvpbf/C7FaB6ZgFU2BWkEN59Vqmjm2s5yz34d+khyxIoNWToTlF0CNcnPuLB XQAJP4ZMXCtoth6gFhVDaGBVRUsYLZRShC+J2KjznW22XBdjfdQiv7Rei+2ArYDvCjiV hIlQ1wy3lLSHMFACcZqNxoMnmOP6B4IPkzDmGpYxhn9cFSsuk1yllrdXUXHLJR8S+VdT q4baULRvVPYpsw9zuAYSMYM4KG9tSOsxyERWVqr3UU+UtTtvxNHHIRogALTwf423xY6J CEw8mIB0LtnR3fJ9/hDITVidEobcG/L7YjtcgTNqUHVTsFTGuaFixvlQroBF7M3pqMeP ArkQ== 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=zeLdtlm5fyG4e4NmZsB12NmZQsKiGBBJ/0OLv9txh08=; b=CJGSR09zBVRQmmRwbHxGNhmdeyqinc5ALz9c46tdfcmENsWQEOAMvKbSWgknlAAuQp VUUbnYMV8vUEj7e8ZwNsXBYyhFkbkuGOaUfQmveLurBnRjn+Mj8+0Y76mE1fynbuzipv zhK/3/MLXx9pCAk731ps25BeVPWrXE690AMQoGSezVJM4PsCxBFJD23BI0ZuJwuog3L6 xqFfCCVdCYCTcOcr2OeUTYUsQCbYGImr0B9rWHFMM4Z36fM8FDY8jj86kmXPcVpQKlTQ jmzquz4W7xWzbWoSDRvdJQ0p7pDESyNLb/lEs5qs8T+dIiwuAuBhof8mmBgmdY0cajmC b8GQ== X-Gm-Message-State: AIkVDXKt8c1vrko0Qw/dvYzNcZADGY6aoEX6SsMnq/TtOU6LgLQKC6yxIwCrs8I6Jtw/Tw== X-Received: by 10.25.167.20 with SMTP id q20mr4937224lfe.115.1484207059925; Wed, 11 Jan 2017 23:44:19 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id s64sm2061121lfs.38.2017.01.11.23.44.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 11 Jan 2017 23:44:18 -0800 (PST) From: "Valery Smyslov" To: "'Scott Fluhrer \(sfluhrer\)'" , "'Michael Richardson'" , "'Tero Kivinen'" References: <8194C08F-F2F9-4B2E-B061-A02106969884@vigilsec.com> <22629.2793.418553.140726@fireball.acr.fi> <7633.1483030288@obiwan.sandelman.ca> <68d87dd3d4974691b9e21294601014d7@XCH-RTP-006.cisco.com> In-Reply-To: <68d87dd3d4974691b9e21294601014d7@XCH-RTP-006.cisco.com> Date: Thu, 12 Jan 2017 10:44:10 +0300 Message-ID: <002201d26ca7$aa037fe0$fe0a7fa0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGf0y3ElAb1MY6fIaqsOC5fSHHzigGoWBMQAZex9aUBz07S3wH8byxnAo0cSouhTN1R8A== Content-Language: ru Archived-At: Cc: 'IETF IPsec' Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 07:44:23 -0000 Hi Scott, > > Would it be reasonable to create some token/nonce from something = before > > the PPK is mixed in such that we could recognize the different AUTH > > FAILUREs, or does that create too much of an oracle for testing = PPKs? >=20 > I believe that would be reasonable. We already exchange notifies = between the two sides (to allow both > sides to know whether or not we're using a PPK); the obvious mention = would be if the notifies included > PRF( PPK, "fixed value" ). That's similar to what I suggested in = https://www.ietf.org/mail-archive/web/ipsec/current/msg11058.html (my proposal only used nonces instead of "fixed value" to decrease = traceability of PPK, if it is ever important). > As for an Oracle, I don't believe that would present a problem; the = general assumption is that PPKs have > enough entropy to be completely unguessable (and if that's assumption = is wrong, this doesn=E2=80=99t make it any > worse). In any case: > - With the current protocol, an active attacker can already determine = whether a guess of the PPK is > correct (assuming they're the side that first receives an encrypted = message after we stir in the PPK, it can > obviously try different PPKs to see which one allows a plausible = decryption). > - With this protocol extension, a passive attacker could plausibly = determine whether the connection > failed due to a PPK mismatch or something else (presumably, the = implementation will react differently due > to the two error modes). It's not at clear whether that leaks any = interesting information; the only way that > an attacker could induce a PPK mismatch on properly configured systems = is by messing with the ID > payloads (PPKs are selected based on the ID payloads), and one would = hope such a modification would > cause a failure earlier. >=20 > So, what does the WG think? Would doing something like this (to allow = both sides to determine a PPK > mismatch vs. some other failure) be important? Would the = informational leakage be a concern? Yes, it is important.=20 Regards, Valery. From nobody Wed Jan 11 23:48: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 A8E8312943E for ; Wed, 11 Jan 2017 23:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 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=3.599, 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 8fBr14qw2LGu for ; Wed, 11 Jan 2017 23:48:14 -0800 (PST) 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 8510E1270B4 for ; Wed, 11 Jan 2017 23:48:14 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id m78so7450193lfg.2 for ; Wed, 11 Jan 2017 23:48:14 -0800 (PST) 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=BHW8g3lZCbG8sGEJ2PuN+6jS/OKoInHA9eFkphoH6Kc=; b=ro5+DczxOhCrQdmvCD7Ih6OfiaI+F/n/oTIq7HHXWkQp69dhwNpFUpg85bcp22Pa1i hvGNokIWdSOfyvHeBLy++/M0NsIfC61UACSafNMevD9GTecSfkd/iUSPOzZYAnJtfvUK e0fmqNrXED/MNzT7kccAzKZ77Nwb6ZFVAunxm2Xg2VuRt9gOe+SFdGqRJ0PHhJGZnibv BlzVyum/RFAPwCpkhXJSeovz2ttqmna2isasHURTXQc9FG4tuikfIHa47UuvumXoi3Ew 1qgMSshhrQ1ZLvu49CB6ZOAPQJhl3USGsx8PmRSSZQGMZqrvbFikeizvpESQcWiPzwAK 9QhQ== 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=BHW8g3lZCbG8sGEJ2PuN+6jS/OKoInHA9eFkphoH6Kc=; b=PdcIlC3mNmMfLzjm1woKG+oDiOqhVAon6gOUXBXluKWAMYWFjZNf1xbWGrvd+47k85 C6WqJUG0zwlLhFpE7I8DBFbq8lk2mYMPhSoNcEgdTpp/1tnzjhu54ehw4bx/MTSUBksu lcFSPa05ztKnp0zQS5f+KeaFx6XSGElEoK4trwIQTLttqNCnGj0181LUkMyWdPNDqgvb xoAjc040lzMOX9jtYHbAyBMPUuAEpGaEimxgERsWi9qDFhchamjKjDgAy7Etm6WjdT6e aZsKQOGugyaDjpaGUWQbSiCDunwh0hoEukDrrjKfPI1sCha0TyZs7XlQQ1Kx5lGbxQw8 QsgQ== X-Gm-Message-State: AIkVDXL33RZ+ZlqNOMgy1Np4MaHXdKk5Gbajko2g57iKbR2fu4StNWKatGfaChEBWLy5Pw== X-Received: by 10.25.74.196 with SMTP id x187mr3952744lfa.30.1484207292740; Wed, 11 Jan 2017 23:48:12 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id s28sm1749528ljd.20.2017.01.11.23.48.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 11 Jan 2017 23:48:11 -0800 (PST) From: "Valery Smyslov" To: "'Michael Richardson'" , "'IETF IPsec'" References: <8194C08F-F2F9-4B2E-B061-A02106969884@vigilsec.com> <22629.2793.418553.140726@fireball.acr.fi> <7633.1483030288@obiwan.sandelman.ca> <68d87dd3d4974691b9e21294601014d7@XCH-RTP-006.cisco.com> <23154.1484143583@obiwan.sandelman.ca> In-Reply-To: <23154.1484143583@obiwan.sandelman.ca> Date: Thu, 12 Jan 2017 10:48:04 +0300 Message-ID: <002301d26ca8$34d426b0$9e7c7410$@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: AQGf0y3ElAb1MY6fIaqsOC5fSHHzigGoWBMQAZex9aUBz07S3wH8byxnAo0cSosB+3ogCgHJiaXToS656QA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Quantum Resistant IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 07:48:15 -0000 Hi Michael, > Scott: how do you think PPKs will get entered initially (i.e. until we have > some quantum-resistant mechanism to distribute them)? Humans typing them > in, QR codes scanned, USB keys sent via Fedex? If we are serious about > this, then it matters. > > If Humans is the answer, then I would like to suggest the document suggest a > standard humen presentation format, such as bubble-babble [first hit: > http://www.wisegeek.com/what-is-bubble-babble.htm. Maybe there is a better > reference]. I think that the way PPKs are entered is out of scope of the protocol. Some suggestions could be listed in the document for informational purposes. Regards, Valery. From nobody Thu Jan 12 00:46: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 CC5FF12896F for ; Thu, 12 Jan 2017 00:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.599 X-Spam-Level: * X-Spam-Status: No, score=1.599 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_SORBS_WEB=3.599, 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 V2ucIK-NTqPL for ; Thu, 12 Jan 2017 00:45:58 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 39DAC1293E1 for ; Thu, 12 Jan 2017 00:45:58 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id k86so8352633lfi.0 for ; Thu, 12 Jan 2017 00:45:58 -0800 (PST) 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=yXzDaDDc9DXGj1yUxr1EagLfZBvp+arq3MPBgXxp/pw=; b=RIQpESW+1xYVe05ZZLumECToRkt6SYDWVU6NTLQUeffS68K18dS106MjMMscrmECn+ xej+RHRgQ1z2H72mb3iCKIsiVGjQwupwW++19M5MYqncLqRjZ/xkQXnJdk8a6Hm5ZtBb PxT2HaOIZPepF5ruk3krZvQY+QzNIU8jMiNy0Hp8Uqu+ikEqrfE69Z1evPXEPRR8LuBZ Q9O74MlU8vDkKQbyaS8IPwIcd7twzgqpE5pid9mcJnm4Yi7u5CNJL+4dczrRm8S/llwg pcigBHUvPgDnrGWWjQXP/WxFiT5P0UIYapDf+oWIwPAnMNhxHelyq6INGylDENMUOZrD yHpg== 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=yXzDaDDc9DXGj1yUxr1EagLfZBvp+arq3MPBgXxp/pw=; b=iMddT47XkMN8Isl8m93PBulw53JSejByY4OkHCoOwQ2trPlbCRXFpBs+OjAWyFogX9 kllXDKpMEgNhQJAkKeU+P88OM9ZJgm1Ambb1q5KZHjT4pS8ACJAiJhYeZKw92r5WNYlM mJ3kFIkOOBWgS3qW2TJ/k+cn+U25mLfb/D4dWrvbUKxKftY4lXDX+unZHIUE42txYX0B cq3d2QcWcuRG6k639Y0+CyRnNJKM/xEujEWF8YyDkykHzE95Y/3uP+4i2cwG1PvRDcng zmn8KTplNI1MV+Za+lUXJ/2tXGuAKWsko2LSmBvLJ27DkRmcT5KpnWcdcQgQTrqh5tJp JJNA== X-Gm-Message-State: AIkVDXIgIKx/3+G5gOsE9WGpvOoOZXqFnOuqlzlHH1WtftvN8EpJ4mhuHGXnAd/m5rFxUg== X-Received: by 10.25.37.80 with SMTP id l77mr4089941lfl.152.1484210756271; Thu, 12 Jan 2017 00:45:56 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id f14sm2095758lff.40.2017.01.12.00.45.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 12 Jan 2017 00:45:55 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" , References: <22644.61072.705632.343770@fireball.acr.fi> In-Reply-To: <22644.61072.705632.343770@fireball.acr.fi> Date: Thu, 12 Jan 2017 11:45:47 +0300 Message-ID: <006501d26cb0$45483650$cfd8a2f0$@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: AQIb0CB4O2sbX/bB60fwKx2UaOL/YKChu4rw Content-Language: ru Archived-At: Subject: Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 08:46:00 -0000 Hi Tero, > -- > >From section 3.2 > > If the CFG_REQUEST included INTERNAL_DNS_DOMAIN attributes with non- > zero lengths, the CFG_REPLY MUST NOT assign any domains in its > INTERNAL_DNS_DOMAIN attributes that are not contained within the > requested domains. The initiator SHOULD ignore any domains beyond > its requested list. > > This whole thing about restricting the subdomains server can send by > sending the list from client is different than what we normally do. In > normal case the client sends list of suggestions for the configuration > values to the server. Here the client forces server to do something. > > I think it would be better to say that client can send list of dns > names it would like to be included, and server can then reply whatever > list it has in its configuration, and client is free to ignore as many > of the items from the list it likes. > > This way if you have originally configured company1.com to the > internal dns names, and then company decides to buy another company > called company2.com, teh client can still request company1.com and > server can return both company1.com and company2.com in its reply. > Then it is up to the client whether it will belive the list or not. Why the client would ever not believe to the information from the authenticated server? I'd go further and say that the initiator MUST use the received internal DNS servers for all the requests within the received INTERNAL_DNS_DOMAIN (as you proposed before). > In section 6: > > If a host connected to an authenticated IKE peer is connecting to > another IKE peer that attempts to claim the same domain via the > INTERNAL_DNS_DOMAIN attribute, the IKE connection should be > terminated. > > Which of the IKE connection should be terminated? Perhaps the first > connection has died and user tried to reconnect to the same server, > which will of course give the same INTERNAL_DNS_DOMAIN. Tearing down > that new connection and not allowing it to be formed until the first > one is timed out is bit annoying. I think that tearing down a connection in this case is wrong and inconsistent with Redirect Mechanism for IKEv2 (RFC5685). There could be several VPN gateways protecting the internal network and the client can be redirected from one to another (or even have a concurrent IKE SAs in case of load sharing scenario). > If the IP address value of the received INTERNAL_IP4_DNS or > INTERNAL_IP6_DNS attribute is not covered by the proposed IPsec > connection, then the local DNS should not be reconfigured until a > CREATE_CHILD Exchange is received that covers these IP addresses. > > I think this is dangerous. I.e. if the server returns INTERNAL_IP4_DNS > of 10.0.0.1 and INTERNAL_DNS_DOMAIN of example.com, but initial Child > sa connection fails for some reason (out of resources). Next the email > client trying to resolve the mail.example.com goes out to the external > dns servers to find the name, instead of trying to use 10.0.0.1 dns > server. Note, that when it tries to send packet to 10.0.0.1, then the > IPsec will simply trigger for that packet, and will create the Child > SA needed... > > So I think the DNS configuration should be done immediately, > regardless whether the Child SA to cover those IP address is there. > In properly configured system the IP-address will then trigger the SA > to be created when they are first time used. I completely agree here. As with internal IP address assignment the failure to create IPsec SA is not a reason not to configure internal DNS servers. Regards, Valery. From nobody Thu Jan 12 05:02: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 0DB8D129640 for ; Thu, 12 Jan 2017 05:02:48 -0800 (PST) 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 HjXt6kYz2KZ8 for ; Thu, 12 Jan 2017 05:02:46 -0800 (PST) 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 30AE6129639 for ; Thu, 12 Jan 2017 05:02:46 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v0CD2eXs013132 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 Jan 2017 15:02:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v0CD2eFA006017; Thu, 12 Jan 2017 15:02:40 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <22647.32368.596076.881346@fireball.acr.fi> Date: Thu, 12 Jan 2017 15:02:40 +0200 From: Tero Kivinen To: Timothy Carlin In-Reply-To: References: X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 17 min X-Total-Time: 13 min Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] Review of draft-ietf-ipsecme-rfc7321bis-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 13:02:48 -0000 Timothy Carlin writes: > My comments: >=20 > * Section 4 mentions that that 256-bit keys are raised to the SHOULD = level.=A0 > Should this read as these are now the MUST level as ENCR=5FAES=5FCBC = and > ENCR=5FAES=5FGCM=5F16 are at the MUST level according to Table 1 (wit= h the [1] > endnote)=3F Yes, I think this is inconsistancy caused by last edits, i.e., when we changed the 256-bit keys to MUST, we only edited the footnote, and missed the text in section 4. So correct change is: OLD: =09=09In that sense 256 bit keys status has been raised from MAY in RFC7321 to SHOULD. NEW: =09=09In that sense 256 bit keys status has been raised from MAY in RFC7321 to MUST. > * Section 5 mentions ENCR=5FNULL=5FAUTH=5FAES=5FGMAC, which is not > referenced anywhere in the document.=A0 Should it be added to Table 1= > at the MUST level=3F No. It is MAY level algorithm, just like the AUTH=5FAES=5F128=5FGMAC an= d AUTH=5FAES=5F256=5FGMAC algorithms. The reason those AUTH=5FAES=5F{128,= 256}=5FGMAC algorithms are listed here is, that they used to be SHOULD+, and are now downgraded to MAY. The ENCR=5FNULL=5FAUTH=5FAES=5FGMAC has been MAY, and will be MAY, so i= t is not mentioned in the section 4. Your text edits seemed to be fine. --=20 kivinen@iki.fi From nobody Thu Jan 12 05:04: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 82A0A12963A for ; Thu, 12 Jan 2017 05:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 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=3.599, 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 KgCvU6SQ4sCL for ; Thu, 12 Jan 2017 05:04:36 -0800 (PST) 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 EF70D129639 for ; Thu, 12 Jan 2017 05:04:35 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id z134so8916382lff.3 for ; Thu, 12 Jan 2017 05:04:35 -0800 (PST) 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=E+q6qCS4isyutq9mrA0AickKfqXJcn87WPvf0jdF1IM=; b=Yc6OV1HI6V1PYmFYBzSSQUev2rBmgHv4WGpFeoMFp9p/KP6R2PulmxWqMWjCPLmPsD /bnWlX/Rml1/pfLXFcNAJBaAppzmsfRhA00n5uEuTTK0EQ2cr6FrWKvLovXI1V6t0D3H Qqk0HpbNoXQwFNxCLF8TDVZI7bwrKp1q3fr79+JrEMBGge5ilW00ypdb+afhJ9eCyO4b u3M7OR31+62FSAvWhSmz7r8tWFdwnpNIYgKKjUi4tud3pjOEzt5ClPsu9WK9Nsn6uS9D rybXj3pDHotdB+Cn6MP3GChMDIeEEr0J03jqoj8zLkuMZJCmR+phG9sRlADKq6vmNG9K BIoQ== 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=E+q6qCS4isyutq9mrA0AickKfqXJcn87WPvf0jdF1IM=; b=hqjH/xq6dLyX1SZKsm7oVV6ypnywrTh2uKp0HFLqAjpT7Q365SsyJjgJMe773QqhO5 wepzdhM9TxGoGaJLWY+KsQAaSCMKdU5Sx1VJQB7pxkamZiROWomx/C9jg2zZB375YjZb 32OfuOP44afxNqGDrrtZMdBavz1AD5YIH9d9GlWDju4u0O4v5hXJEfXHkmQ1ZBp+yy4P N+sN1+lO40dWzqrTe2jH7r+TujyzkeHgBylzTC+GS4oa2aJa+OR0pr1CbMrTMDlLNcuu dKM5XNMmTNpIhslWEBXMNNQSwdhKfkKmNtGG34xxapZuTv7b5yyWsz3JF3dDj1KhNp8x zJCA== X-Gm-Message-State: AIkVDXLmBi1ief2XRe71TCInXbqklRaSblLWx47xJf0VjI2GUuOIQ7upcrA5okQSdx0t8Q== X-Received: by 10.25.219.69 with SMTP id s66mr4655853lfg.116.1484226273639; Thu, 12 Jan 2017 05:04:33 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id t25sm2331606lja.38.2017.01.12.05.04.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 12 Jan 2017 05:04:32 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" , References: <22646.18786.629023.688752@fireball.acr.fi> In-Reply-To: <22646.18786.629023.688752@fireball.acr.fi> Date: Thu, 12 Jan 2017 16:04:24 +0300 Message-ID: <00f901d26cd4$663324a0$32996de0$@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: AQCkxeybEg8DzyV7FTOC0kNdz/A/IKOQBjIQ Content-Language: ru Archived-At: Subject: Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 13:04:37 -0000 Hi once more, > The streams of data sent over any TCP connection used for this > protocol MUST begin with the stream prefix value followed by a > complete message, which is either an encapsulated IKE or ESP message. > ... > > I think this should be rephrased in a way that when initiator creates > new TCP connection, it MUST send the stream prefix value first, > followed by a IKE or ESP message. > > The responder might receive them in pieces, because of the TCP, so > responder should not consider it an error to only receive stream > prefix and parts of the first message. If it sees partial message it > should wait for the rest of the message to come or untile timeout > occurs. Note, the responder do need timeout in this case, as we do > want to clean up the state if we have partial messages in the TCP > stream, even when the TCP connection itself is not broken. And it should be specified that if responder times out waiting for complete IKE message, it must not only delete IKE SA state, but also it must close TCP connection, so that initiator get informed that it must start over from creating new TCP connection and resending the whole message. Otherwise if the TCP eventually resumes, the responder will receive partial message which it'll treat as invalid (I assume that the responder has already read from the socket some part of the message, like length prefix) and the TCP connection will be closed anyway. > -- > > If the connection is being used to resume a previous IKE session, the > responder can recognize the session using either the IKE SPI from an > encapsulated IKE message or the ESP SPI from an encapsulated ESP > message. > > There should be note here and later explaining that this IKE or ESP > message must pass authentication checks, and MUST be fresh. I.e., > replaying old IKE or ESP message over tcp stream must not move traffic > to new TCP connection. This text here tells which IKE it belongs, but > later three is text saying: > > It should choose the TCP > connection on which it last received a valid and decryptable IKE or > ESP message. > > so that should also include note, that messages must be fresh. Note, > that definition of fresh is not obvious. For the ESP it is not enough > that it is unseen message in the replay window, as the replay window > might be quite large, and acquiring ESP message not seen by the other > end is quite possible. I think it is best to require that the ESP > message must be with higher sequence number ever seen before... This will be always true with TCP. > This should be happening anyways, as there will not be reordering happening > inside the TCP connection, so this will not cause issues for normal > cases. > > Same for the IKE SA, i.e. the message-id must be larger than anything > seen before, not just something that is in the window. Isn't it easier to add a requirement that the received message must not be a replay? For example: It should choose the TCP connection on which it last received a valid and decryptable IKE or ESP message that is not recognized as a replay of some early message. > -- > > In section 9: > > fragmentation. Even if fragmentation is negotiated, an > implementation MAY choose to not fragment when going over a TCP > connection. > > why allow fragmentation over TCP connection? I think we could say that > fragmentation SHOULD NOT be used when sending messages over TCP > connection? The only reason I can think why someone would use > fragmentation is that they are using mobike and the initiator is using > UDP and tries to send some large message which requires fragmentation > on UDP first, and then when the packets do not get through it tries to > move to use TCP, and in that case it MUST forward the IKE packet just > as it was sent over the UDP to the TCP, so the packet will have > fragmentation headers in it. > > So I would say MUST accept packets with fragmentation from TCP if > fragmentation is supported and enabled. SHOULD NOT fragment packets if > sending them to the TCP connection. I agree with your comment here, however I can see a reason for MAY - some implementations may have a single configuration knob, that triggers between "always fragment" and "never fragment". These implementations may choose to always fragment (if the knob is on) regardless of the used transport just for simplicity. Regards, Valery. From nobody Thu Jan 12 05:09: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 6DE6D129614 for ; Thu, 12 Jan 2017 05:09:35 -0800 (PST) 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 NwZzSffIn7Hm for ; Thu, 12 Jan 2017 05:09:34 -0800 (PST) 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 0F172129604 for ; Thu, 12 Jan 2017 05:09:33 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v0CD9VZZ027071 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 Jan 2017 15:09:31 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v0CD9VRk014534; Thu, 12 Jan 2017 15:09:31 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22647.32779.383413.871691@fireball.acr.fi> Date: Thu, 12 Jan 2017 15:09:31 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <006501d26cb0$45483650$cfd8a2f0$@gmail.com> References: <22644.61072.705632.343770@fireball.acr.fi> <006501d26cb0$45483650$cfd8a2f0$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 4 min Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 13:09:35 -0000 Valery Smyslov writes: > > This way if you have originally configured company1.com to the > > internal dns names, and then company decides to buy another company > > called company2.com, teh client can still request company1.com and > > server can return both company1.com and company2.com in its reply. > > Then it is up to the client whether it will belive the list or not. > > Why the client would ever not believe to the information from the > authenticated server? I'd go further and say that the initiator MUST > use the received internal DNS servers for all the requests within > the received INTERNAL_DNS_DOMAIN (as you proposed before). The level of trust might not be complete. I.e., if my laptop is connecting to both my own VPN gateway, and also one of our partners VPN gateway, I might trust the VPN gateway of our my company even if it claims to provide trusted DNS delegation for .com... I might not want to trust the VPN gateway of our partner claiming to be authorative for mycompany.com, i.e., I will have policy limiting what is accepted from the gateway. Also when using opportunistic authentication we might want to have even strictier policies. -- kivinen@iki.fi From nobody Thu Jan 12 05:17:48 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 A506A1293DA for ; Thu, 12 Jan 2017 05:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 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=3.599, 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 HLu6PA-1bsZO for ; Thu, 12 Jan 2017 05:17:45 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 10D9F1279EB for ; Thu, 12 Jan 2017 05:17:45 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id z134so9155991lff.3 for ; Thu, 12 Jan 2017 05:17:44 -0800 (PST) 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=o0DfdGRSN+8jAvSg2AHqW4f/cYZdxedRvgj26JIU70U=; b=mz8BANVdMso3Ru0ptto9Qigbw6dfoUD4+RH+KF7uTgkv810soyhJMEKolNSGczw5rz MwT572xtQAg8pgOzwnd0Ikkqu0nF6JtTKJDpzOpVhn0o0eULLkWJpySCG/p5RJBLvdTN Ln5Wo1K5V3b6Hv4ncUYosS6DGj1/nQ9Zz2W1Kuc9oC3+d7vA6opJz8411Tp52RzRKbzo TVMYtfJEdUl02Eo7D1M4x1l6buAjoDNWsBgyqotXXNrVQJzbWyXamjKcMPdv5Nfa5JfP f9IrzjtnZbz+35nV8owsIWNXmHme+sho0OA2N1mAnL0eOQZcLNPgn1gj1uWXWJmC9NIW U1Tg== 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=o0DfdGRSN+8jAvSg2AHqW4f/cYZdxedRvgj26JIU70U=; b=bWkT00NtTEpQr0M5imulKHojOEOVf7O18uvwRflZkqdxWXTA17H0VQ8eLWLdlMh7kj GxjzHcP5szd/8GDeVY7U3XO3qAFR0fETFjhUKMB9W6UcH6tIeWamE/RQoCCqPayROFKr pjUIjbguYpS96Y01lzUputgb7TSaN7V9wMxFVhGuhnbt/JPH4xNE6mvryu9iZdaXjspA uzBXn+HeAr3f0bXJhKEXJta8R2r2dJCo5edMQTDL+VF7OES3btHbkvP9lv/vHv2p2jEk TLsfMrRRtQSZipwh7wtDWKh8TvCFmWP5UfhcWbLBnpA1oS2LlTKdqIWT8gb3km9aJ30z OiFw== X-Gm-Message-State: AIkVDXJ7Z5GKqePiOHeGsSKmb9wqYB7e8Yc/iIuqa2vYB31ztFPxzs06r2+RfxbMs/VfrA== X-Received: by 10.46.7.26 with SMTP id 26mr5503194ljh.18.1484227063005; Thu, 12 Jan 2017 05:17:43 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id c78sm2300429lfc.39.2017.01.12.05.17.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 12 Jan 2017 05:17:42 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" References: <22644.61072.705632.343770@fireball.acr.fi> <006501d26cb0$45483650$cfd8a2f0$@gmail.com> <22647.32779.383413.871691@fireball.acr.fi> In-Reply-To: <22647.32779.383413.871691@fireball.acr.fi> Date: Thu, 12 Jan 2017 16:17:34 +0300 Message-ID: <00fa01d26cd6$3cd83850$b688a8f0$@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: AQIb0CB4O2sbX/bB60fwKx2UaOL/YAFAglLAAsl5DSeggbq0sA== Content-Language: ru Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 13:17:46 -0000 > > > This way if you have originally configured company1.com to the > > > internal dns names, and then company decides to buy another company > > > called company2.com, teh client can still request company1.com and > > > server can return both company1.com and company2.com in its reply. > > > Then it is up to the client whether it will belive the list or not. > > > > Why the client would ever not believe to the information from the > > authenticated server? I'd go further and say that the initiator MUST > > use the received internal DNS servers for all the requests within > > the received INTERNAL_DNS_DOMAIN (as you proposed before). > > The level of trust might not be complete. I.e., if my laptop is > connecting to both my own VPN gateway, and also one of our partners > VPN gateway, I might trust the VPN gateway of our my company even if > it claims to provide trusted DNS delegation for .com... > > I might not want to trust the VPN gateway of our partner claiming to > be authorative for mycompany.com, i.e., I will have policy limiting > what is accepted from the gateway. > > Also when using opportunistic authentication we might want to have > even strictier policies. OK, then it contradicts with your own comment that all requests to INTERNAL_DNS_DOMAIN MUST be done using internal DNS server. Quoting your message: I think the 1st point (I.e. all requests about internal names go to the internal servers) is something that is important for security, so it should perhaps be MUST. At least it must be clarified. From nobody Thu Jan 12 05:37: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 8063F12963E for ; Thu, 12 Jan 2017 05:37:40 -0800 (PST) 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 cLjjRlHSE-_n for ; Thu, 12 Jan 2017 05:37:39 -0800 (PST) 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 1A5B5129631 for ; Thu, 12 Jan 2017 05:37:38 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v0CDbZg9013148 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 Jan 2017 15:37:35 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v0CDbZIb025103; Thu, 12 Jan 2017 15:37:35 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22647.34463.288872.263903@fireball.acr.fi> Date: Thu, 12 Jan 2017 15:37:35 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <00f901d26cd4$663324a0$32996de0$@gmail.com> References: <22646.18786.629023.688752@fireball.acr.fi> <00f901d26cd4$663324a0$32996de0$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 24 min X-Total-Time: 14 min Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 13:37:40 -0000 Valery Smyslov writes: > > This should be happening anyways, as there will not be reordering happening > > inside the TCP connection, so this will not cause issues for normal > > cases. > > > > Same for the IKE SA, i.e. the message-id must be larger than anything > > seen before, not just something that is in the window. > > Isn't it easier to add a requirement that the received message must > not be a replay? For example: > > It should choose the TCP > connection on which it last received a valid and decryptable IKE or > ESP message that is not recognized as a replay of some early message. No. Not replay == ESP packet we have not seen before that is still in window != ESP packet which has largest sequence number. I.e., attacker sends RST to the tcp connection, initiator recreates TCP session, and initiator sends one ESP packet to the TCP connection having sequence number of 0x1000. Attacker messes up with the TCP connection so that responder never sees the ESP 0x1000 packet, and TCP connection is reset. For example sends RST before the actual packet reaches the responder, but after the attacker has seen the contents of the packet in TCP stream. Initiator then recreates tcp session with responder and sends some ESP traffic with sequence numbers of 0x1001-0x1005. Attacker kills that TCP connection, creates completely new TCP session and replays the old ESP message with sequence number of 0x1000 (which was not seen by the server before). Responder will accept this as valid non replayed ESP packet, and will move all traffic to this new TCP connection. The attack is not very efficient, and there are most likely easier ways to do similar attacks, but there might be some other tricks people might invent if we leave this thing open. Thats why I think it is better to close it by saying that it is not enough to have valid ESP packet which is not replay, but it must be valid ESP packet which have sequence number that is higher than anything seen before. One way of implementing that is to configure ESP replay window size to be 1... > > So I would say MUST accept packets with fragmentation from TCP if > > fragmentation is supported and enabled. SHOULD NOT fragment packets if > > sending them to the TCP connection. > > I agree with your comment here, however I can see a reason for MAY - > some implementations may have a single configuration knob, that > triggers between "always fragment" and "never fragment". > These implementations may choose to always fragment > (if the knob is on) regardless of the used transport just for simplicity. So we are allowing this kind of stupid things because there might be some implementation that will implement this new protocol and which does not want to fix their own broken implementation about fragmentation? I assume they do not really care about the fragment sizes, and will fragment everything to 100 byte fragments, just because of simplicity? Again SHOULD will not prevent that, and MUST accept will allow them to work... Hmm.. and the responder SHOULD respond with fragments too if I read RFC7383 right... On the other hand sending fragments to the TCP connection is already against SHOULD NOT in the RFC7383 which says that "IKE fragmentation SHOULD NOT be used in cases where IP-layer fragmentation of both the request and response messages is unlikely."... So I think SHOULD NOT fragment is correct here, as it is directly derived from the RFC7383... -- kivinen@iki.fi From nobody Thu Jan 12 05:48: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 52874128874 for ; Thu, 12 Jan 2017 05:48:35 -0800 (PST) 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 tqoVGTakroGF for ; Thu, 12 Jan 2017 05:48:34 -0800 (PST) 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 B9E73127077 for ; Thu, 12 Jan 2017 05:39:52 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v0CDdoUO013689 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 Jan 2017 15:39:50 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v0CDdoXC027848; Thu, 12 Jan 2017 15:39:50 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22647.34598.54930.382704@fireball.acr.fi> Date: Thu, 12 Jan 2017 15:39:50 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <00fa01d26cd6$3cd83850$b688a8f0$@gmail.com> References: <22644.61072.705632.343770@fireball.acr.fi> <006501d26cb0$45483650$cfd8a2f0$@gmail.com> <22647.32779.383413.871691@fireball.acr.fi> <00fa01d26cd6$3cd83850$b688a8f0$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 1 min Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 13:48:35 -0000 Valery Smyslov writes: > > > > This way if you have originally configured company1.com to the > > > > internal dns names, and then company decides to buy another company > > > > called company2.com, teh client can still request company1.com and > > > > server can return both company1.com and company2.com in its reply. > > > > Then it is up to the client whether it will belive the list or not. > > > > > > Why the client would ever not believe to the information from the > > > authenticated server? I'd go further and say that the initiator MUST > > > use the received internal DNS servers for all the requests within > > > the received INTERNAL_DNS_DOMAIN (as you proposed before). > > > > The level of trust might not be complete. I.e., if my laptop is > > connecting to both my own VPN gateway, and also one of our partners > > VPN gateway, I might trust the VPN gateway of our my company even if > > it claims to provide trusted DNS delegation for .com... > > > > I might not want to trust the VPN gateway of our partner claiming to > > be authorative for mycompany.com, i.e., I will have policy limiting > > what is accepted from the gateway. > > > > Also when using opportunistic authentication we might want to have > > even strictier policies. > > OK, then it contradicts with your own comment that all requests to > INTERNAL_DNS_DOMAIN MUST be done using internal DNS server. > Quoting your message: > > I think the 1st point (I.e. all requests about internal names go to > the internal servers) is something that is important for security, so > it should perhaps be MUST. > > At least it must be clarified. Yes, and No. If the client rejects the INTERNAL_DNS_DOMAIN because of policy reasons, then it is not internal name anymore, thus it can use DNS server configured elsewhere. But yes, I agree there should be clarification explaining that only those internal names client accepted must use internal servers... -- kivinen@iki.fi From nobody Thu Jan 12 06:32: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 71BBD12948E for ; Thu, 12 Jan 2017 06:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 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=3.599, 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 fPN9QLDuk7P6 for ; Thu, 12 Jan 2017 06:32:13 -0800 (PST) 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 15CE51293F0 for ; Thu, 12 Jan 2017 06:32:13 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id k86so14185337lfi.0 for ; Thu, 12 Jan 2017 06:32:12 -0800 (PST) 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=qbJQdnC/TPyqRVVeNmdBjeH70Yktar63ES51GH+Zt50=; b=EJN5nihpWO81Ry6BRTVQGi2A9lZMzD3eKbz3bvbDaF8BmzIY78KpLqhm66Wysv8Feg TGTqrKrb8KcAwdzpzM6A7Q/axw3veGWmJM4dU732LNpSSOJmBviB2Eg2d9S8e+X0hn0X zxNHImsEYkc5r3fmakgOu+V741Z1dIx9GnFNXcg7kOaiXryrIlR6TB7z1UYUI8x4WXgY Ec7rk5QYu4PMuP3TIA+K91iSXdbsRqUMBtkJg/bOT7txcmYX5oXtOdU3MR7XJWgyg2/N ZC3xdNcA2NJG+rICbg7dnmcEU1jsnF+Qb8gGlbGmzvDshp7CnuiToHTH/6JXlCSS9P4L 5PlQ== 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=qbJQdnC/TPyqRVVeNmdBjeH70Yktar63ES51GH+Zt50=; b=Vh4iTzfzaTIq6vR9T5WadA1J+g0Jbrm2mT2KbefA5AaRboHCI95GJ7UQ/5t/k5++KU Fk4T9HaE7b6YbP5aFLHkahcJEz+dCEVXkTDbuOyTlebtHWpM4FyYFQlAT1PP/qpmuiTQ 61Ql5IBHrogqAqf0GHclElQMUiZz6IMejP0uGwapnRkAh0eMkLd08VPAOU0X1CBPnKPw Bf6S3m6ZwJVyP302OhaPlZUH16r84Qj9A0VbXRzI2ZgqyTvo0hwuaJRSIo29Q4VzBc81 Mm54rL0amV3IFV/SF73lgcUaxK+PP/h+p6yGFlgUvK7DHDNH93omp04wxDUXSinB+c+0 dHvQ== X-Gm-Message-State: AIkVDXJhbye8CkFtGFJ0gw3jmQOPXgCMYqwkzjUZW8pKRKu0cuzbetgn6A+ULCRSY81Wbg== X-Received: by 10.46.5.196 with SMTP id 187mr5194803ljf.36.1484231531149; Thu, 12 Jan 2017 06:32:11 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id e23sm2398737lji.29.2017.01.12.06.32.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 12 Jan 2017 06:32:10 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" References: <22646.18786.629023.688752@fireball.acr.fi> <00f901d26cd4$663324a0$32996de0$@gmail.com> <22647.34463.288872.263903@fireball.acr.fi> In-Reply-To: <22647.34463.288872.263903@fireball.acr.fi> Date: Thu, 12 Jan 2017 17:32:02 +0300 Message-ID: <010701d26ce0$a4183650$ec48a2f0$@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: AQCkxeybEg8DzyV7FTOC0kNdz/A/IAJquEvpArBjo1KjZ1bbIA== Content-Language: ru Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 14:32:14 -0000 > > Isn't it easier to add a requirement that the received message must > > not be a replay? For example: > > > > It should choose the TCP > > connection on which it last received a valid and decryptable IKE or > > ESP message that is not recognized as a replay of some early message. > > No. > > Not replay == ESP packet we have not seen before that is still in > window != ESP packet which has largest sequence number. > > I.e., attacker sends RST to the tcp connection, initiator recreates > TCP session, and initiator sends one ESP packet to the TCP connection > having sequence number of 0x1000. Attacker messes up with the TCP > connection so that responder never sees the ESP 0x1000 packet, and TCP > connection is reset. For example sends RST before the actual packet > reaches the responder, but after the attacker has seen the contents of > the packet in TCP stream. > > Initiator then recreates tcp session with responder and sends some ESP > traffic with sequence numbers of 0x1001-0x1005. Attacker kills that > TCP connection, creates completely new TCP session and replays the old > ESP message with sequence number of 0x1000 (which was not seen by the > server before). Responder will accept this as valid non replayed ESP > packet, and will move all traffic to this new TCP connection. What then? What benefits attacker gains and how it will exploit the fact it hijacks TCP connection? The responder will eventually recreate new TCP connection and everything will continue to work. The reason I opposed your interpretation of "fresh" is that if you replace ESP with IKE in the example above and if you require the responder to ignore smaller MESSAGE_IDs if the higher are received, then the responder will ignore IKE message with ID=0x1000 in your example, because this message will be received after the responder receives 0x1001-0x1005. Since the initiator will never receive reply for ID=0x1000 it will eventually kill IKE SA. This is much more dangerous attack than the attack you described above. > The attack is not very efficient, and there are most likely easier > ways to do similar attacks, but there might be some other tricks > people might invent if we leave this thing open. Thats why I think it > is better to close it by saying that it is not enough to have valid > ESP packet which is not replay, but it must be valid ESP packet which > have sequence number that is higher than anything seen before. For IKE it'll make things worse. > One way of implementing that is to configure ESP replay window size to > be 1... That's probably OK, since TCP will provide in-order delivery. However, that will further complicate implementations, because you'll need to be able to dynamically manipulate ESP window size in case the transport changes. And IKE doesn't allow window to shrink, so we'll stick to size = 1. Not a good idea. From nobody Thu Jan 12 06:57: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 3A1001296DF for ; Thu, 12 Jan 2017 06:57:10 -0800 (PST) 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 hgMrMtwuQAbT for ; Thu, 12 Jan 2017 06:57:08 -0800 (PST) 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 0A933129474 for ; Thu, 12 Jan 2017 06:57:07 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v0CEv3cG016060 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 Jan 2017 16:57:03 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v0CEv3eB013760; Thu, 12 Jan 2017 16:57:03 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22647.39231.75549.135863@fireball.acr.fi> Date: Thu, 12 Jan 2017 16:57:03 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <010701d26ce0$a4183650$ec48a2f0$@gmail.com> References: <22646.18786.629023.688752@fireball.acr.fi> <00f901d26cd4$663324a0$32996de0$@gmail.com> <22647.34463.288872.263903@fireball.acr.fi> <010701d26ce0$a4183650$ec48a2f0$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 21 min X-Total-Time: 10 min Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 14:57:10 -0000 Valery Smyslov writes: > > Initiator then recreates tcp session with responder and sends some ESP > > traffic with sequence numbers of 0x1001-0x1005. Attacker kills that > > TCP connection, creates completely new TCP session and replays the old > > ESP message with sequence number of 0x1000 (which was not seen by the > > server before). Responder will accept this as valid non replayed ESP > > packet, and will move all traffic to this new TCP connection. > > What then? What benefits attacker gains and how it will exploit > the fact it hijacks TCP connection? The responder will eventually > recreate new TCP connection and everything will continue to work. As I said this is not serious, but it is vulnerability, which is easy to fix. There might be tricks you can do (for example forward multigigabyte video stream from server to some unsuspecting client, while the original recipient is just wondering where is my video, until after few minutes it times out and tries to recreate the TCP session, or sends new packet through the TCP session. > The reason I opposed your interpretation of "fresh" is that > if you replace ESP with IKE in the example above and if you > require the responder to ignore smaller MESSAGE_IDs if > the higher are received, then the responder will ignore > IKE message with ID=0x1000 in your example, because > this message will be received after the responder receives 0x1001-0x1005. > Since the initiator will never receive reply for ID=0x1000 > it will eventually kill IKE SA. This is much more dangerous > attack than the attack you described above. IKE will not have this issue, as every single IKE frame will require response, thus if the original initiator did not get IKE response to his request when the attacker killed the connection, then it will retransmit when it recreates the TCP session. This only really affects ESP, not IKE. Also in IKE the window size is quite often also 1. And, I am not saying they should ignore the messages, I say they should not consider the messages as fresh, meaning they should not turn old traffic to that new TCP session until they see fresh message. > > The attack is not very efficient, and there are most likely easier > > ways to do similar attacks, but there might be some other tricks > > people might invent if we leave this thing open. Thats why I think it > > is better to close it by saying that it is not enough to have valid > > ESP packet which is not replay, but it must be valid ESP packet which > > have sequence number that is higher than anything seen before. > > For IKE it'll make things worse. And I was talking about ESP. Not IKE. For IKE there is no problem there as there is always response, thus blackholes are detected. For ESP there can be problems. > > One way of implementing that is to configure ESP replay window size to > > be 1... > > That's probably OK, since TCP will provide in-order delivery. > However, that will further complicate implementations, because > you'll need to be able to dynamically manipulate ESP window > size in case the transport changes. > > And IKE doesn't allow window to shrink, so we'll stick to > size = 1. Not a good idea. Again, I do not think this is needed for IKE, I think it is needed for ESP. With ESP it is possible for the attacker to redirect the packets from the server to wrong address for long time, by just sending few packets, and the situation might be fixed only after the original initiator wonders where his packets are and starts to do corrective actions. (and IKE window can shrink, as rekey resets the window size to 1). -- kivinen@iki.fi From nobody Thu Jan 12 07:26:07 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 B0F16129880 for ; Thu, 12 Jan 2017 07:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 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=3.599, 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 5gRzNzfPL3WN for ; Thu, 12 Jan 2017 07:26:02 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 DF86312987F for ; Thu, 12 Jan 2017 07:26:01 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id m78so15238215lfg.2 for ; Thu, 12 Jan 2017 07:26:01 -0800 (PST) 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=upHdkXXQ23H8qeHPybsYS8RAcBBndaE4mFVPW4OOweM=; b=Lp98rbWcohnFp+Wv0OC7wsc6tIq+MNsArH7a+jtzsTuhWOUeU/6axPpJxpEIVr1Rqb 9HZ3HUfVK/d4+8pP+7vV6JtVX5QLiDjmi/3ykBoheQlZyhrANyqFKs1CN1In0Pn/XIen VzWy94oTBYDJsN6vpe2Jd/stGirSlAZIGTxLnwic0BrzxBpGCXpGYyVEwvDmeV+eAJVF YnF/zk3eSbHW+hljlNSqC2v+zEWk4W48L4LwvQliukYBUUdQMUtdswETp5wK/kQ7bIr+ 9/khhNQLabhyrUUjam6QesquLwGjJWS51YAuPlPwDyeif7r7+Bek3yD6/itZaIagmg7q yJ4Q== 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=upHdkXXQ23H8qeHPybsYS8RAcBBndaE4mFVPW4OOweM=; b=X10p91eEOgy/IrSrHv9UAfHiE93aRXrZdeJkaesf/EENO+eA2NYBf096ATRwY2qo+U vNO8i3LCSVBn70PR2tBFyqV5Dw9/+dpu9z6XPmYwo6K6TJj3HefCs52ONYa19EWL3Ld2 DdqAuxyWySaZnaH0LzFrEdGHJf0J0da25qHa1LmBpmwKcfIFuiLixpEKGdPqsOsDwoIm VSCWB7qBxnApmprKJbedYemsjlhix3VawBwSGpQzFw1tujc3dQe+99rVKM+vfvahJMy5 5II2C2O+2lDxUPabOF4ghFZNtw0fpj8jj2xKMPseQsn7QLPWbAEv5PZqh/RK6eIrZpsY 64DQ== X-Gm-Message-State: AIkVDXK980XpyvxmRLG51PyzOSyjo0lSh/WzqLn+Fu35Rjx6R3syfnW9QyHzQB+wufr/Lw== X-Received: by 10.46.69.139 with SMTP id s133mr5631203lja.56.1484234759925; Thu, 12 Jan 2017 07:25:59 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 85sm1303663lfr.37.2017.01.12.07.25.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 12 Jan 2017 07:25:58 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" References: <22646.18786.629023.688752@fireball.acr.fi> <00f901d26cd4$663324a0$32996de0$@gmail.com> <22647.34463.288872.263903@fireball.acr.fi> <010701d26ce0$a4183650$ec48a2f0$@gmail.com> <22647.39231.75549.135863@fireball.acr.fi> In-Reply-To: <22647.39231.75549.135863@fireball.acr.fi> Date: Thu, 12 Jan 2017 18:25:50 +0300 Message-ID: <010801d26ce8$2885b730$79912590$@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: AQCkxeybEg8DzyV7FTOC0kNdz/A/IAJquEvpArBjo1ICBR++NAJDHJCso0UkmSA= Content-Language: ru Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 15:26:06 -0000 > > > Initiator then recreates tcp session with responder and sends some ESP > > > traffic with sequence numbers of 0x1001-0x1005. Attacker kills that > > > TCP connection, creates completely new TCP session and replays the old > > > ESP message with sequence number of 0x1000 (which was not seen by the > > > server before). Responder will accept this as valid non replayed ESP > > > packet, and will move all traffic to this new TCP connection. > > > > What then? What benefits attacker gains and how it will exploit > > the fact it hijacks TCP connection? The responder will eventually > > recreate new TCP connection and everything will continue to work. > > As I said this is not serious, but it is vulnerability, which is easy > to fix. I don't think your fix really helps in this scenario. If attacker intercepts TCP session carrying ESP packet with sequence 0x1000 and manages to get the packet and drop the TCP session before responder gets it, then it can create a new TCP session sending this packet. The responder will switch to the attacker's TCP session even with your proposal (until the initiator creates new TCP session and sends some ESP packets with higher SN). From nobody Thu Jan 12 09:02:34 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 3068D12949D for ; Thu, 12 Jan 2017 09:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 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=-3.199] 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 3IVBF9zCvqbm for ; Thu, 12 Jan 2017 09:02:31 -0800 (PST) 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 97F41128BA2 for ; Thu, 12 Jan 2017 09:02:31 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tzsWR0kSTz1c3; Thu, 12 Jan 2017 18:02:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1484240547; bh=vtCOxhWzftXhhHj0BEUSrY2aN5JtNhEKt538IaA6EMs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MSpzcd0F64n2xPpt1swju5jHaLbkZNePcwibZ/UX8iVNgWlPENNuidt5LOz8phheb NWNmrZFXQC4EWsjGbytOEiNW5B/Vbgc8MyNiBM0+evksKy0wTL8K3TEBfIaM+5/teg CGaKJUDrNU3hs7HhMiI7A/00Qd0pFZ0l8Z303dmI= 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 kd0gsfecDDiC; Thu, 12 Jan 2017 18:02:25 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 12 Jan 2017 18:02:25 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5D6396ED5BA; Thu, 12 Jan 2017 12:02:21 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 5D6396ED5BA Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 41762407E856; Thu, 12 Jan 2017 12:02:21 -0500 (EST) Date: Thu, 12 Jan 2017 12:02:21 -0500 (EST) From: Paul Wouters To: Tero Kivinen In-Reply-To: <22647.34598.54930.382704@fireball.acr.fi> Message-ID: References: <22644.61072.705632.343770@fireball.acr.fi> <006501d26cb0$45483650$cfd8a2f0$@gmail.com> <22647.32779.383413.871691@fireball.acr.fi> <00fa01d26cd6$3cd83850$b688a8f0$@gmail.com> <22647.34598.54930.382704@fireball.acr.fi> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org, Valery Smyslov Subject: Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 17:02:33 -0000 On Thu, 12 Jan 2017, Tero Kivinen wrote: >>> I might not want to trust the VPN gateway of our partner claiming to >>> be authorative for mycompany.com, i.e., I will have policy limiting >>> what is accepted from the gateway. >>> >>> Also when using opportunistic authentication we might want to have >>> even strictier policies. >> >> OK, then it contradicts with your own comment that all requests to >> INTERNAL_DNS_DOMAIN MUST be done using internal DNS server. >> Quoting your message: >> >> I think the 1st point (I.e. all requests about internal names go to >> the internal servers) is something that is important for security, so >> it should perhaps be MUST. >> >> At least it must be clarified. > > Yes, and No. If the client rejects the INTERNAL_DNS_DOMAIN because of > policy reasons, then it is not internal name anymore, thus it can use > DNS server configured elsewhere. But yes, I agree there should be > clarification explaining that only those internal names client > accepted must use internal servers... Remember ipsec is peer to peer, not client to server :) The idea is that the client can convey information of which DNS it will allow to be stolen and the server can convey which DNS it is serving that is expected to be an internal dns domain (eg different from outside worldview). This is not about the server offering a DNS server to take all your queries. For that, I believe you can use the existing options, and those are outside the scope of this document. Paul From nobody Thu Jan 12 10:15:48 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 6FC8C1294D5 for ; Thu, 12 Jan 2017 10:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.656 X-Spam-Level: X-Spam-Status: No, score=-8.656 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, RCVD_IN_MSPIKE_H2=-1.156, RP_MATCHES_RCVD=-3.199, 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 rOVAyhrwyd8t for ; Thu, 12 Jan 2017 10:15:43 -0800 (PST) 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 C9A5512945F for ; Thu, 12 Jan 2017 10:15:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1484244927; 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=KK2S6bhBZzQ/qXhJQFQCRUpJXGnjDBFtgOk7IrQr4U8=; b=tlrd1YvJG8vts/WxObhf7mQ9Ta1MYmZFqjst1Nc+5ac2l+qdNFt39uPm6DhwPE7Q ApuEwnY7bY8mlfpuWx0EH4UvXLxzKyA3Yfz2To6wWUp2oVkwtQD0rMQpbW8r8368 Ha+hCW8zbgetwClGNxzI3Bq9lHwR1Co8I+y/uLIhm508iGdZT+uJnBosVgx4d7q2 93QJ2YF9VMkYKzbWTm0Kv3BTyN99gLXmYXOiNbgEEU76hAMiynbGh80sVLVVKWiA oaiRMAZ9O9lDIwm/3oRbvleRl+LaUmNXGJWuPm3UFG8wP4Iqj3m/4LF3xqawa6me qA/IsVsbkEN7PiyPq9nRoA==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 8E.62.05063.097C7785; Thu, 12 Jan 2017 10:15:23 -0800 (PST) X-AuditID: 11973e16-99e949a0000013c7-e0-5877c7ac46a7 Received: from nwk-mmpp-sz07.apple.com (nwk-mmpp-sz07.apple.com [17.128.115.240]) by relay2.apple.com (Apple SCV relay) with SMTP id 70.67.09148.267C7785; Thu, 12 Jan 2017 10:13:54 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.226.23.78] (unknown [17.226.23.78]) by nwk-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OJO00H74IN5TO10@nwk-mmpp-sz07.apple.com>; Thu, 12 Jan 2017 10:13:54 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <22646.18786.629023.688752@fireball.acr.fi> Date: Thu, 12 Jan 2017 10:13:53 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <22646.18786.629023.688752@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3301.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUi2FDorLv/eHmEwfqlJhb7t7xgszh6/jmb A5PHkiU/mTwOf13IEsAUxWWTkpqTWZZapG+XwJXR/GkOU8GVkIqDLRcZGxgfO3UxcnJICJhI 7OjZwtTFyMUhJLCXUeLK9jVMMImLK/uZIRKHGCUePLoOluAVEJT4MfkeSxcjBwezgLrElCm5 IGEhgQ4miQ9/C0DCwgISEpv3JIKEhQWcJboen2cGsdkEVCSOf9vADFLCKWAh8XyeMojJIqAq MfdQEUgFs4CQxMIFWxkhbG2JJ+8usELstJE4+Ogj2E4hAXOJnafBdooIKErsfrIV6l55icb5 7awg90oIbGGTeLJgCfsERuFZSE6ehXDyLCQbFjAyr2IUyk3MzNHNzDPXSywoyEnVS87P3cQI CujpdmI7GB+usjrEKMDBqMTDK2BfFiHEmlhWXJl7iFGag0VJnLdkNVBIID2xJDU7NbUgtSi+ qDQntfgQIxMHp1QDY+yGGVH100v8zmv+K1tXqeU28Xy9fjHbxkxj3RLrrG9HZgYdn/J8odAn rwsyCVfa4hhk1jusN+WYY5ge+3LD61/LF6191XzqhPWi9D8JhhUhrUnW8mH/Vuydut7pQNJ1 ns77JwKPtU95m/hJ58beRdpaahnbT9wXWy50e2Fl8cm/s32DxOu9timxFGckGmoxFxUnAgCA j5moSQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUi2FD8QTfpeHmEwdpD/Bb7t7xgszh6/jmb A5PHkiU/mTwOf13IEsAUxWWTkpqTWZZapG+XwJXR/GkOU8GVkIqDLRcZGxgfO3UxcnJICJhI XFzZzwxhi0lcuLeerYuRi0NI4BCjxINH15lAErwCghI/Jt9j6WLk4GAWUJeYMiUXJCwk0MEk 8eFvAUhYWEBCYvOeRJCwsICzRNfj82Aj2QRUJI5/28AMUsIpYCHxfJ4yiMkioCox91ARSAWz gJDEwgVbGSFsbYkn7y6wQuy0kTj46CPYTiEBc4mdp8F2iggoSux+spUJ4l55icb57awTGAVn IblyFsKVs5AMXcDIvIpRoCg1J7HSSC+xoCAnVS85P3cTIzgwC513MB5bZnWIUYCDUYmHV8C+ LEKINbGsuDIXGAwczEoivCbHyiOEeFMSK6tSi/Lji0pzUosPMSYDfTKRWUo0OR8YNXkl8YYm JgYmxsZmxsbmJuakCSuJ8/pL5kQICaQnlqRmp6YWpBbBbGHi4JRqYOS9/e1tn9yS9D2dAmc7 mk5N6buZGe7/mEfgEEP3kU+bXYKsL77ReDmZ1eNrdIgCd03e0e7EkF2NCxuVzz4PdpoY1Cn1 bIt/WZt7OuPUmU1qTZdsfu0PTDurMsfj16pjsyMXFH35YXNid/7/iEeH5/ju9jbiUJ6xr2PO s9lKr9v7XmvP6dv/pEmJpTgj0VCLuag4EQBcNowNkAIAAA== Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 18:15:46 -0000 Hi Tero, Thanks for the comments! Responses inline. Best, Tommy > On Jan 11, 2017, at 7:04 AM, Tero Kivinen wrote: >=20 > This draft should be quite ready for the WGLC, so I will start that > shortly, but here are comments from my chair review of the draft. >=20 > Consider these comments just like any WGLC comments. >=20 > -- >=20 > In section 6, there is text saying: >=20 > In order to close an IKE session, either the initiator or responder > SHOULD gracefully tear down IKE SAs with DELETE payloads. Once all > SAs have been deleted, the initiator of the original connection MUST > close the TCP connection. >=20 > I do not understand the reasoning behind the MUST, or actually also > whether it is that it MUST be initiator of the original connection > closing, it or that connection MUST be closed after all SAs are > deleted. >=20 > If it is supposed to say that once all SAs are deleted the connection > MUST be deleted, then it does not really matter who will close it, as > once all SAs are gone, there cannot be any new IKE exchanges on the > TCP connection. >=20 > If it is trying to say that only original initiator can close the > connection, just in case it wants to reuse it for new IKE INIT > message, then the text needs to change to say that. >=20 > I.e., what is this MUST trying to say? This MUST should probably be downgraded to a SHOULD, and add explanation = about the reuse case. The point of this text was to make sure that = initiators don=E2=80=99t needlessly leave TCP connections open to = responders, and take up resources on the responder. A better text would = be: "In order to close an IKE session, either the initiator or responder SHOULD gracefully tear down IKE SAs with DELETE payloads. Once all SAs have been deleted, the initiator of the original connection SHOULD close the TCP connection if it does not intend to use the connection = for another IKE session to the responder. If the connection is left idle, and the responder needs to clean up resources, the responder MAY close the TCP connection." >=20 > -- >=20 >=20 > The streams of data sent over any TCP connection used for this > protocol MUST begin with the stream prefix value followed by a > complete message, which is either an encapsulated IKE or ESP = message. > ... >=20 > I think this should be rephrased in a way that when initiator creates > new TCP connection, it MUST send the stream prefix value first, > followed by a IKE or ESP message. >=20 > The responder might receive them in pieces, because of the TCP, so > responder should not consider it an error to only receive stream > prefix and parts of the first message. If it sees partial message it > should wait for the rest of the message to come or untile timeout > occurs. Note, the responder do need timeout in this case, as we do > want to clean up the state if we have partial messages in the TCP > stream, even when the TCP connection itself is not broken. Good point, I will clarify the text to make it clearer that the prefix = value must be sent first on any new connection, and that the responder = has to deal with parsing partial messages. >=20 > -- >=20 > If the connection is being used to resume a previous IKE session, = the > responder can recognize the session using either the IKE SPI from an > encapsulated IKE message or the ESP SPI from an encapsulated ESP > message. >=20 > There should be note here and later explaining that this IKE or ESP > message must pass authentication checks, and MUST be fresh. I.e., > replaying old IKE or ESP message over tcp stream must not move traffic > to new TCP connection. This text here tells which IKE it belongs, but > later three is text saying: >=20 > It should choose the TCP > connection on which it last received a valid and decryptable IKE or > ESP message. >=20 > so that should also include note, that messages must be fresh. Note, > that definition of fresh is not obvious. For the ESP it is not enough > that it is unseen message in the replay window, as the replay window > might be quite large, and acquiring ESP message not seen by the other > end is quite possible. I think it is best to require that the ESP > message must be with higher sequence number ever seen before... This > should be happening anyways, as there will not be reordering happening > inside the TCP connection, so this will not cause issues for normal > cases. >=20 > Same for the IKE SA, i.e. the message-id must be larger than anything > seen before, not just something that is in the window. I will add text to specify that the IKE and ESP messages must be valid = (pass authentication and decryption), and have higher IDs than previous = messages. >=20 > Also why this text has only lowercase "should", not uppercase MUST?=20 I may want to upgrade it to a SHOULD. If we are in a state in which = there are, for a time, two TCP connections up, the only reliable way to = return a message from the responder to the initiator is to use the most = recently-used TCP connection. However, if a responder implementation did = send a response packet on the less-recently used connection, it *might* = get back to the initiator. This would probably require some special = knowledge about how the implementations were using connections, but if = that use case comes up in the future, I don=E2=80=99t think sending a = packet on the other connection would necessarily make the implementation = out-of-spec. However, if consensus is that this should be a MUST rather = than a SHOULD, I=E2=80=99m fine with that! >=20 > -- >=20 > If either initiator or responder receives a stream that > cannot be parsed correctly, it MUST close the TCP connection. >=20 > I think this needs more text. I.e., if it receives random garbage, > then it must close the TCP connection. But if it receives > authenticated IKEv2 message, which passes IKE SA message > authentication, but which is cannot be parsed correctly (i.e., result > in the INVALID_SYNTAX error), then it will return INVALID_SYNTAX > error, tear down the IKE SA (as specified in the RFC7296) and close > the TCP connection. Good point. I=E2=80=99ll try to word this generically=E2=80=94i.e., any = parsing of the IKE and ESP frames should cause the connection to be = closed, and any errors within IKE that cause the IKE session to be torn = down should do the same. >=20 > -- >=20 > Multiple IKE SAs SHOULD NOT share a single TCP connection. >=20 > I think this needs to be MUST NOT. I mean if we assume that the first > IKE or ESP message coming from the newly formed TCP connection tells > which IKE SA this TCP connection belongs, we cannot really use one TCP > connection for multiple IKE SAs. >=20 > Of course we should allow IKE SA rekeying over the same TCP > connection, but I think that is only exception to the multiple IKE SAs > using same TCP connection, and in that case the one end will delete > the old rekeyed IKE SA soon. >=20 > So I would change that to MUST, and add note about rekeying case. Sure, that sounds fine. I could imagine that if two IKE SAs were on the = same connection, another message=20 >=20 > -- >=20 > In section 7 we should also mention that the fact whether there is NAT > or not in the path can affect the TCP and UPD packet checksum fixup > for transport mode traffic (RFC7296 section 2.23.1). Will add. >=20 > -- >=20 > In section 8, there is text: >=20 > When an IKE session is transitioned between networks using MOBIKE > [RFC4555], the initiator of the transition may switch between using >=20 > MOBIKE is not property of the networks, it is property of the > implementations. I.e., change this to say "When an IKE session is > created between implementations using MOBIKE, =E2=80=A6" Yes, that=E2=80=99s not clear. I meant =E2=80=9CWhen an IKE session that = has negotiated MOBIKE is transitioning between networks, the = initiator=E2=80=A6" >=20 > -- >=20 > In section 9: >=20 > fragmentation. Even if fragmentation is negotiated, an > implementation MAY choose to not fragment when going over a TCP > connection. >=20 > why allow fragmentation over TCP connection? I think we could say that > fragmentation SHOULD NOT be used when sending messages over TCP > connection? The only reason I can think why someone would use > fragmentation is that they are using mobike and the initiator is using > UDP and tries to send some large message which requires fragmentation > on UDP first, and then when the packets do not get through it tries to > move to use TCP, and in that case it MUST forward the IKE packet just > as it was sent over the UDP to the TCP, so the packet will have > fragmentation headers in it. >=20 > So I would say MUST accept packets with fragmentation from TCP if > fragmentation is supported and enabled. SHOULD NOT fragment packets if > sending them to the TCP connection. We can switch it to a SHOULD NOT for sending fragments, and a MUST for = accepting fragments. Depending on how implementations are built, the IKE = logic may not be co-located with the module handling UDP or TCP, and so = I expect some implementations to still use fragmentation in the naive = case. >=20 > -- >=20 > In the security considerations section we should also mention that > attackers can do quite a lot of same tricks explained in the MOBIKE > [RFC4555] security considerations. Perhaps put pointer to there, and > think that list through and list which of those can be done also when > using TCP connection. The TCP connection has same kind of properties > than MOBIKE, as it will allow changing the source IP and port of the > incoming connection, and SGW will update its mapping to match the > latest connection=E2=80=A6 >=20 Will add the reference and section discussing the implications of = changing the source IP and port mappings. > -- >=20 > In section B.1, the IKE messages should have "Non-ESP Marker" visible > on the figure 4. Will add. >=20 > -- >=20 > In section B.3, there should be the one mandatory IKE or ESP packet > after the "IKETCP" stream prefix. Perhaps use ESP here as example=E2=80=A6= Will add. >=20 > -- >=20 > In section B.4 step 6 should note, that this message in step 6, is > actually retransmission of the message sent in step 2, i.e., it is > exactly same IKE message including message-id and the contents. Good point, that will make the diagram clearer. > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Jan 12 11:13: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 4EAEB12951E for ; Thu, 12 Jan 2017 11:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Uepi1xedINI4 for ; Thu, 12 Jan 2017 11:13:31 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 972B0127078 for ; Thu, 12 Jan 2017 11:13:31 -0800 (PST) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 7CBE81EDF682A; Thu, 12 Jan 2017 19:13:27 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id v0CJDTPk028416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jan 2017 19:13:30 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id v0CJDRTT029732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jan 2017 19:13:29 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.74]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0301.000; Thu, 12 Jan 2017 14:13:28 -0500 From: "Hu, Jun (Nokia - US)" To: Valery Smyslov , "'Tero Kivinen'" Thread-Topic: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04 Thread-Index: AQHSbBwDlGBDL3K21kWbkChwnCX2d6E1JGQAgAAJRoCAAA82AIAABv6AgAAICgD//+o/kA== Date: Thu, 12 Jan 2017 19:13:30 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BEB9014D@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <22646.18786.629023.688752@fireball.acr.fi> <00f901d26cd4$663324a0$32996de0$@gmail.com> <22647.34463.288872.263903@fireball.acr.fi> <010701d26ce0$a4183650$ec48a2f0$@gmail.com> <22647.39231.75549.135863@fireball.acr.fi> <010801d26ce8$2885b730$79912590$@gmail.com> In-Reply-To: <010801d26ce8$2885b730$79912590$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 19:13:34 -0000 I think this is similar case as NAT-T , where system need to update address= :port if NAT mapping is changed ( described in last point of 2.23 of RFC729= 6 );=20 RFC 7296 says: "dynamic address update should only be done in response to a new packet; otherwise, an attacker can revert the addresses with old replayed packets. Because of this, dynamic updates can only be done safely if replay protection is enabled." I think we could use same requirement (pass anti-replay) here since this is= same issue and tcp encap is not make thing worse;=20 > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Valery Smyslov > Sent: Thursday, January 12, 2017 7:26 AM > To: 'Tero Kivinen' > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04 >=20 > > > > Initiator then recreates tcp session with responder and sends some > > > > ESP traffic with sequence numbers of 0x1001-0x1005. Attacker kills > > > > that TCP connection, creates completely new TCP session and > > > > replays the old ESP message with sequence number of 0x1000 (which > > > > was not seen by the server before). Responder will accept this as > > > > valid non replayed ESP packet, and will move all traffic to this ne= w TCP > connection. > > > > > > What then? What benefits attacker gains and how it will exploit the > > > fact it hijacks TCP connection? The responder will eventually > > > recreate new TCP connection and everything will continue to work. > > > > As I said this is not serious, but it is vulnerability, which is easy > > to fix. >=20 > I don't think your fix really helps in this scenario. >=20 > If attacker intercepts TCP session carrying ESP packet with sequence > 0x1000 and manages to get the packet and drop the TCP session before > responder gets it, then it can create a new TCP session sending this pack= et. > The responder will switch to the attacker's TCP session even with your > proposal (until the initiator creates new TCP session and sends some ESP > packets with higher SN). >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Jan 13 01:39:54 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 299271294A2 for ; Fri, 13 Jan 2017 01:39:53 -0800 (PST) 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 pC2InruhWyFr for ; Fri, 13 Jan 2017 01:39:51 -0800 (PST) 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 EC10612944F for ; Fri, 13 Jan 2017 01:39:50 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v0D9di4R013746 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Jan 2017 11:39:44 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v0D9di1w029241; Fri, 13 Jan 2017 11:39:44 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22648.41056.227333.906463@fireball.acr.fi> Date: Fri, 13 Jan 2017 11:39:44 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <010801d26ce8$2885b730$79912590$@gmail.com> References: <22646.18786.629023.688752@fireball.acr.fi> <00f901d26cd4$663324a0$32996de0$@gmail.com> <22647.34463.288872.263903@fireball.acr.fi> <010701d26ce0$a4183650$ec48a2f0$@gmail.com> <22647.39231.75549.135863@fireball.acr.fi> <010801d26ce8$2885b730$79912590$@gmail.com> 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: Cc: ipsec@ietf.org Subject: Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 09:39:53 -0000 Valery Smyslov writes: > > > > Initiator then recreates tcp session with responder and sends some ESP > > > > traffic with sequence numbers of 0x1001-0x1005. Attacker kills that > > > > TCP connection, creates completely new TCP session and replays the old > > > > ESP message with sequence number of 0x1000 (which was not seen by the > > > > server before). Responder will accept this as valid non replayed ESP > > > > packet, and will move all traffic to this new TCP connection. > > > > > > What then? What benefits attacker gains and how it will exploit > > > the fact it hijacks TCP connection? The responder will eventually > > > recreate new TCP connection and everything will continue to work. > > > > As I said this is not serious, but it is vulnerability, which is easy > > to fix. > > I don't think your fix really helps in this scenario. > > If attacker intercepts TCP session carrying ESP packet with sequence > 0x1000 and manages to get the packet and drop the TCP session before > responder gets it, then it can create a new TCP session > sending this packet. The responder will switch to the attacker's > TCP session even with your proposal (until the initiator > creates new TCP session and sends some ESP packets with higher SN). But he cannot take the ESP packet stolen half an hour ago, which still happens to be in 128 packet ESP replay window. Also he cannot steal 20 packets from the window, and play them one by one, every time original responder tries to get his TCP session back. We had this same problem with NAT traversal with UDP packets, i.e. attacker stealing some packets can always redirect the traffic to wrong peer, once per each stolen packet. In NAT traversal we cannot do anything, as there can be out of order packets. With MOBIKE this was fixed by using UPDATE_SA_ADDRESS notification to update the addresses. Here we can make the things better even for ESP packets, as there should not be reordered packets, thus requiring latest sequence number to update the address does not cause issues. -- kivinen@iki.fi From nobody Fri Jan 13 01:50:10 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 E61321294A2 for ; Fri, 13 Jan 2017 01:50:08 -0800 (PST) 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 ccLls8ugVkCE for ; Fri, 13 Jan 2017 01:50:07 -0800 (PST) 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 8C2AF1270B4 for ; Fri, 13 Jan 2017 01:50:07 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v0D9o4BT020845 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Jan 2017 11:50:04 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v0D9o4cD005197; Fri, 13 Jan 2017 11:50:04 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22648.41676.334598.15442@fireball.acr.fi> Date: Fri, 13 Jan 2017 11:50:04 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <22644.61072.705632.343770@fireball.acr.fi> <006501d26cb0$45483650$cfd8a2f0$@gmail.com> <22647.32779.383413.871691@fireball.acr.fi> <00fa01d26cd6$3cd83850$b688a8f0$@gmail.com> <22647.34598.54930.382704@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 8 min Archived-At: Cc: ipsec@ietf.org, Valery Smyslov Subject: Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 09:50:09 -0000 Paul Wouters writes: > > Yes, and No. If the client rejects the INTERNAL_DNS_DOMAIN because of > > policy reasons, then it is not internal name anymore, thus it can use > > DNS server configured elsewhere. But yes, I agree there should be > > clarification explaining that only those internal names client > > accepted must use internal servers... > > Remember ipsec is peer to peer, not client to server :) Yes, but configuration payloads for endpoint from the tunnel endpoint (section 1.1.3), is not peer to peer, it is client to server :-) > The idea is that the client can convey information of which DNS it will > allow to be stolen and the server can convey which DNS it is serving > that is expected to be an internal dns domain (eg different from outside > worldview). For endpoint to security gateway setup (RFC7296 section 1.1.3) the endpoint is usually configured to trust the tunnel endpoint, but endpoint might also have some of its own configuration for example from previous runs. I.e. endpoint can offer these are the domains I configured last time, and server will respond those look good. Or the server can respond, those look good, but add this new domain, as my configuration has changed since last time. The reason client might want to keep track of the old internal dns domains is that it might want to block the dns for those domains while the vpn is not up, and even trigger the vpn creation when some application tries to resolve one of those domains. > This is not about the server offering a DNS server to take all your > queries. For that, I believe you can use the existing options, and > those are outside the scope of this document. This is about the server offering a DNS server to take some of your queries, but not all. And the defintion of some is intersection of the servers and clients policies. I.e., what server is willing to offer, and what client is willing to accept. -- kivinen@iki.fi From nobody Fri Jan 13 03:43:22 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 7DDFF129B43 for ; Fri, 13 Jan 2017 03:43:20 -0800 (PST) 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 nX8VTiiFEzno for ; Fri, 13 Jan 2017 03:43:18 -0800 (PST) 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 3FA3D129489 for ; Fri, 13 Jan 2017 03:43:18 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v0DBh8nh008610 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Jan 2017 13:43:08 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v0DBh7JI010903; Fri, 13 Jan 2017 13:43:07 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22648.48459.686427.557564@fireball.acr.fi> Date: Fri, 13 Jan 2017 13:43:07 +0200 From: Tero Kivinen To: Tommy Pauly In-Reply-To: References: <22646.18786.629023.688752@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 32 min X-Total-Time: 112 min Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 11:43:20 -0000 Tommy Pauly writes: > This MUST should probably be downgraded to a SHOULD, and add > explanation about the reuse case. The point of this text was to make > sure that initiators don=E2=80=99t needlessly leave TCP connections o= pen to > responders, and take up resources on the responder. A better text > would be:=20 >=20 > "In order to close an IKE session, either the initiator or responder > SHOULD gracefully tear down IKE SAs with DELETE payloads. Once all= > SAs have been deleted, the initiator of the original connection SHO= ULD > close the TCP connection if it does not intend to use the connectio= n for > another IKE session to the responder. If the connection is left idl= e, > and the responder needs to clean up resources, the responder MAY > close the TCP connection." Much better text, this I can understand and agree... > > Same for the IKE SA, i.e. the message-id must be larger than anythi= ng > > seen before, not just something that is in the window. >=20 > I will add text to specify that the IKE and ESP messages must be > valid (pass authentication and decryption), and have higher IDs than > previous messages. Actually Valery did raise good point, that for IKE this might cause issues. Now when I am thinking about this, I think that for IKE packets the response to the IKE request should go to the same TCP session where the request came in. This would be aligned with the RFC7296 which says you reverse ip-addresses and ports for incoming IKE request, and reply to that address. I.e., if you get request 5 in using tcp connection 1, you send your response to connection 1, if you another request 6 coming in using connection 2, you send your response to connection 2. If you then see retransmission of the same request 6 from connection 1, you resend your response to connection 1. I.e., it might be that connection 2 is not working properly, for example return packets do not get through. This kind of things can happen if for example NAT or firewall in the middle is blocking inbound traffic for some ports or something. For new requests the IKE should use the same TCP session than what is being used for ESP, i.e., the most fresh one. The most fresh should then be defined as the one which has received ESP sequence number which is not out of order (note, that there might be multipe ESP SAs in the same TCP connection, so largest sequence number is not right way to express this), or which has received new IKE request (note, not IKE respose, or retrasmitted request) last. --=20 kivinen@iki.fi From nobody Tue Jan 17 12:46:33 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66DF11294A3; Tue, 17 Jan 2017 12:46:32 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148468599241.32122.7027964048689524216.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2017 12:46:32 -0800 Archived-At: Cc: ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-rfc4307bis@ietf.org, David Waltermire Subject: [IPsec] Last Call: (Algorithm Implementation Requirements and Usage Guidance for IKEv2) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 20:46:32 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Algorithm Implementation Requirements and Usage Guidance for IKEv2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-01-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updates RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jan 19 23:18: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 6FF6B129A28 for ; Thu, 19 Jan 2017 23:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 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=3.599, 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 CDO11EzirKey for ; Thu, 19 Jan 2017 23:18:06 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30A19129A26 for ; Thu, 19 Jan 2017 23:18:06 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id z134so51571137lff.3 for ; Thu, 19 Jan 2017 23:18:06 -0800 (PST) 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=AffSnWX1k5ZjkI/l2PV9CchlXGcCjSh/zhuGMBd/b2M=; b=LhN1VQDt/Wn9H+pdxK5musfXVIoWmXwilmJdDDX0wH6E7/v4mphFdFBOebJwJ9kMv6 BSSGamlEsHm8YQQp7O/4s5eWmHmm74mzEszuXkUQl8/Mc4hgRRNvCNlDUVG1yIEDL+Dt OIu/JebwqwZOpykFbv+6IQ735SBepUZJO2B1YPH6J/1PFZSWuuE6JDm2SEiYDuPKpscr Lgcj+Y22CBRRplxw05Bh9Lx1gTIkXTinOgqMe3u/A0obc9y2yQsL2CEYu21Hplut0kgP qkMkEsNa1t3FL8yAxiWrWOTnQUlIpYbYcv9JnTHZshr1ZaxowVQLWG6ya+hrKuQFRwgo fl0g== 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=AffSnWX1k5ZjkI/l2PV9CchlXGcCjSh/zhuGMBd/b2M=; b=h713Fs0LeSS5MSra9f5LqEiN0Iw/HOu2KHA6wy7rzOYuLVfJM7JTtx1fjn/tSmf9dH TJxh4Dt0aFtKJgYmqkOPSmePgADeY6iyCy0B51L0JKe1lf4WGe3roB2aea7+8AhIl9fY P6rhYY7xYP6jJ9tE9kbDsL5elexLkZYzsGieLMgoZjsRAWKc7DC8hB+hjUsbTkdUT1m4 7/jZIfZNy0pLuEbUcUaFdrrC0I4tY+cJqIfphO37awLkiPGlVRD6bzzH9RlL4zlB1sL/ xRpf0khdyZDoMETtIaoi9AaXfmcb8PnPAAzjgMi6OCO1TgBQF5LsCl0fybv0Q+RgulKz fuUQ== X-Gm-Message-State: AIkVDXJ9oEJjDOxlMNTHgr3dvt/PI/df0HGL++BMj90mV+n7JNxsp4hW1DDUtGlkTLdSrQ== X-Received: by 10.25.167.20 with SMTP id q20mr4348513lfe.115.1484896684094; Thu, 19 Jan 2017 23:18:04 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id a138sm2949884lfb.2.2017.01.19.23.18.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 Jan 2017 23:18:03 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" References: <22646.18786.629023.688752@fireball.acr.fi> <00f901d26cd4$663324a0$32996de0$@gmail.com> <22647.34463.288872.263903@fireball.acr.fi> <010701d26ce0$a4183650$ec48a2f0$@gmail.com> <22647.39231.75549.135863@fireball.acr.fi> <010801d26ce8$2885b730$79912590$@gmail.com> <22648.41056.227333.906463@fireball.acr.fi> In-Reply-To: <22648.41056.227333.906463@fireball.acr.fi> Date: Fri, 20 Jan 2017 10:18:05 +0300 Message-ID: <068801d272ed$584ad300$08e07900$@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: AQCkxeybEg8DzyV7FTOC0kNdz/A/IAJquEvpArBjo1ICBR++NAJDHJCsAhfmiRcB/8MDVKMwcjHQ Content-Language: ru Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 07:18:07 -0000 Hi Tero, > > If attacker intercepts TCP session carrying ESP packet with sequence > > 0x1000 and manages to get the packet and drop the TCP session before > > responder gets it, then it can create a new TCP session > > sending this packet. The responder will switch to the attacker's > > TCP session even with your proposal (until the initiator > > creates new TCP session and sends some ESP packets with higher SN). > > But he cannot take the ESP packet stolen half an hour ago, which still > happens to be in 128 packet ESP replay window. Also he cannot steal 20 > packets from the window, and play them one by one, every time original > responder tries to get his TCP session back. So what? If an attacker is so powerful that it can steal ESP packets, block delivering them to the responder and replay these packets later, it doesn't really matter whether it is latest ESP packet (with the highest SN) or some previous packet. The attacker can easily manipulate values in IP and TCP headers of stolen packets, so that the responder will try to send packet back to probably non-existing address/port. > We had this same problem with NAT traversal with UDP packets, i.e. > attacker stealing some packets can always redirect the traffic to > wrong peer, once per each stolen packet. In NAT traversal we cannot do > anything, as there can be out of order packets. With MOBIKE this was > fixed by using UPDATE_SA_ADDRESS notification to update the addresses. > > Here we can make the things better even for ESP packets, as there > should not be reordered packets, thus requiring latest sequence number > to update the address does not cause issues. Sure, but it won't help against this kind of attack. Regards, Valery. From nobody Thu Jan 19 23: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 E53B5129A40 for ; Thu, 19 Jan 2017 23:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 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=3.599, 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 CxYKtpbLzU9q for ; Thu, 19 Jan 2017 23:47:41 -0800 (PST) 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 C3F8D1294DD for ; Thu, 19 Jan 2017 23:47:40 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id z134so51945730lff.3 for ; Thu, 19 Jan 2017 23:47:40 -0800 (PST) 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=rlolQlt5jemDp76C3CYVlk5mtfiuGoUkRtKwfv2rJao=; b=Dchmdy9KirmU9qECapX2cTyp5cOzJXuFy3ion7/dtFdQ4rgMG/7QTTIyC8rPqdCjue jwAxcFzIK9abaAZu0vQ1rHpeIHgHgZsgYS6a/mstuUIHYJSBntB8CPP9Pj2HI9GJ1jLr yzT7bu3EDnlafWwIKGO9m8plWuB4OJKYuTZaRsGOudAkknuP92HYlG9EOhgZLKI2PdBW kx9Cwg9WRcUkzqeWDM89wW47hTmaXOviw684ic0BJ2QT+MTZlXY1fg6vQnz+/gfOqd4/ Tk3cGKjczNvq2ZqZkVd4eHDJHp+cd7j/hwRZjwK3LC24NwiV5PY9b/CN9nuj1/z0b/6I RKeg== 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=rlolQlt5jemDp76C3CYVlk5mtfiuGoUkRtKwfv2rJao=; b=kb1wE0z4SsvVntNLjgUvyG3ToTrmVRWwwy69mAb6tRuaMh5820BFsO6XH1tqJJmShz ZTchRUAO7i03CenjAbFuRsw1sBz+B3rTQrt7lKvEAUffkUmsZGEAhu8JFmeDEOMjUIxx UcNFnLRUaZXXw0ZrcSCKoqtRCaOmv4mHtppaifnox7/1lqCHgHBMgPCYKsJmAAjii/TB MtDmWYx4/pmif66YMFuNlzL16qPQ4nMVKkIPka5yr2O+vJHax4bCliZOdunXOtnyrgCq u8O2YiUe8HYpyQTU8bRZKNXcLxmn5wlVZYBRqJx9zvt52+dro+NBMx10HAuLoDMD+Yav NLwQ== X-Gm-Message-State: AIkVDXJhWm1DHgAgaGHfLJIEBFtg2y3JqYy8svRR2bJlhygE9nMKXWxs6+vc4V5TNdS7Eg== X-Received: by 10.46.78.1 with SMTP id c1mr5641287ljb.75.1484898458854; Thu, 19 Jan 2017 23:47:38 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id j87sm2962257lfi.25.2017.01.19.23.47.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 Jan 2017 23:47:37 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" , "'Tommy Pauly'" References: <22646.18786.629023.688752@fireball.acr.fi> <22648.48459.686427.557564@fireball.acr.fi> In-Reply-To: <22648.48459.686427.557564@fireball.acr.fi> Date: Fri, 20 Jan 2017 10:47:40 +0300 Message-ID: <068a01d272f1$7a1a6280$6e4f2780$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCkxeybEg8DzyV7FTOC0kNdz/A/IAHrtaY8Aixlbgyje44xwA== Content-Language: ru Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 07:47:42 -0000 HI Tero, > Actually Valery did raise good point, that for IKE this might cause > issues. > > Now when I am thinking about this, I think that for IKE packets the > response to the IKE request should go to the same TCP session where > the request came in. This would be aligned with the RFC7296 which says > you reverse ip-addresses and ports for incoming IKE request, and reply > to that address. That makes sense. > For new requests the IKE should use the same TCP session than what is > being used for ESP, i.e., the most fresh one. > > The most fresh should then be defined as the one which has received > ESP sequence number which is not out of order (note, that there might > be multipe ESP SAs in the same TCP connection, so largest sequence > number is not right way to express this), or which has received new > IKE request (note, not IKE respose, or retrasmitted request) last. It doesn't really help to prevent attack, but unnecessary complicates implementations. I'd rather suggest to choose the TCP connection over which the latest valid ESP or IKE packet (that is not a retransmission) is received. In most cases this is equivalent to the rules you suggests (since TCP prevents reordering the latest packet will have the highest SN/MID). In case of powerful attacker on the path, who can steal, drop, modify and replay packets, the rules you suggest won't help anyway. Regards, Valery. From nobody Fri Jan 20 08:02: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 3899B1296EA for ; Fri, 20 Jan 2017 08:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.656 X-Spam-Level: X-Spam-Status: No, score=-8.656 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, RCVD_IN_MSPIKE_H2=-1.156, RP_MATCHES_RCVD=-3.199, 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 1vn0BusHWf40 for ; Fri, 20 Jan 2017 08:02:38 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (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 F33F31293DF for ; Fri, 20 Jan 2017 08:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1484928157; 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=TiJOP7Oba/odhy/1/8w4KFov+uC7J6K9lWXU+ECABbU=; b=KdccV/hCgOnTpzX1PCqaGieQ/tfzXI+2wyUkLdIkn/qhmPDHHkDIGbVP00tBqu+c Ix/mhIBoQ1FAgxhMdoD2VgJIhDFHeyybS2N4lC5CY8fKXxVugaZ+Qexhg9PSj+k+ fc2Sx2ZnBVw2moShRDaTlGvdSf1CKUSlhpKYsw5BKQRI4l4d2GZJpicFVV60kHVZ zT98niCh9UZUMBSef5ii65F7Z3tIDW49CBcC+POyPJ11nPZYim4g2QXdn44pY3e0 DCE0uXSiP+kv+5/2FvI5zdjeK88CHwTDivOFPJSIJ1DAcnE5Ld3JzSn1MIaO/ufK AUvbKyg2BnV82GBIGX3CGg==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 1B.E0.30082.D9432885; Fri, 20 Jan 2017 08:02:37 -0800 (PST) X-AuditID: 11973e15-6bed29a000007582-57-5882349d6526 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 E8.DC.27929.D9432885; Fri, 20 Jan 2017 08:02:37 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.71.234] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OK30091E5WCQR30@nwk-mmpp-sz11.apple.com>; Fri, 20 Jan 2017 08:02:37 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <068a01d272f1$7a1a6280$6e4f2780$@gmail.com> Date: Fri, 20 Jan 2017 08:02:36 -0800 Message-id: <1C45F99E-A4E0-421F-837E-5BE2F825F9FD@apple.com> References: <22646.18786.629023.688752@fireball.acr.fi> <22648.48459.686427.557564@fireball.acr.fi> <068a01d272f1$7a1a6280$6e4f2780$@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUi2FAYoTvXpCnC4MQbI4v9W16wWRw9/5zN 4saHmWwOzB47Z91l91iy5CeTx+GvC1kCmKO4bFJSczLLUov07RK4Mv7/ucZa8Im/YtfXRewN jId4uhg5OSQETCRa3hxgBrGFBPYySuxbVgwT//vrOFT8EKPE3q/mIDavgKDEj8n3WLoYOTiY BeQlDp6XBQkzC2hJfH/UChTmAip/xyix5+8qNpAaYQEJic17EkFqhAWcJboenwcbySagInH8 2wZmkBJOAQuJ31MEQMIsAqoSTz5tYocYaSjRt+QHI8RWG4mXSztZIcYfY5R4+moPG0hCBKjh 5rafzBAny0p0L5wGZc9hk9j503wCo/AsJFfPQrh6FpKrFzAyr2IUyk3MzNHNzDPTSywoyEnV S87P3cQICvPpdqI7GM+ssjrEKMDBqMTDu+NEQ4QQa2JZcWXuIUZpDhYlcd4s/8YIIYH0xJLU 7NTUgtSi+KLSnNTiQ4xMHJxSDYzFhr4Cx1SNyzrU5topVB66oD7/a9+7iZ8n7f/zrZvh6cOd e+Qb9jyurLgy/dzps8/8t4txvFqUys8fIHhQ7+DKuHr11xu3HXix7nXW5mWrXCaV8qgulj5r 5WY0faFY/eJPvy60x0XueVe6VeZyytufHFnxQae2hfNwO3q1yr4+6mu36vP6MPeDSizFGYmG WsxFxYkAy2vALVQCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUi2FA8W3euSVOEwYSHmhb7t7xgszh6/jmb xY0PM9kcmD12zrrL7rFkyU8mj8NfF7IEMEdx2aSk5mSWpRbp2yVwZfz/c4214BN/xa6vi9gb GA/xdDFyckgImEj8/XWcGcIWk7hwbz0biC0kcIhRYu9XcxCbV0BQ4sfkeyxdjBwczALyEgfP y4KEmQW0JL4/agUKcwGVv2OU2PN3FRtIjbCAhMTmPYkgNcICzhJdj8+DjWcTUJE4/m0DM0gJ p4CFxO8pAiBhFgFViSefNrFDjDSU6FvygxFiq43Ey6WdrBDjjzFKPH21B+w0EaCGm9t+Qp0s K9G9cBrzBEbBWUgunYVw6Swkly5gZF7FKFCUmpNYaaqXWFCQk6qXnJ+7iREcsoUROxj/L7M6 xCjAwajEw5twrCFCiDWxrLgyFxgSHMxKIryPNZsihHhTEiurUovy44tKc1KLDzFKc7AoifNe 7q+PEBJITyxJzU5NLUgtgskycXBKNTA6553kFYneqSTqsWK/2vpfO6+VegYUfoz7ucn/3N7N 03n/d079WcurcNat+FTkFdPEefqp71N13vtelLMSfXYloTHD7pmA9KIpIfeLtjlMWCTAcKN1 4emn6WVx7bkZ17nWCLfVGuq/2HL4K4vv8tyGNtFX69eaM2jPW5DLwDi/yK/JyWbmd3klluKM REMt5qLiRAApRbdEVQIAAA== Archived-At: Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 16:02:39 -0000 > On Jan 19, 2017, at 11:47 PM, Valery Smyslov wrote: > > HI Tero, > >> Actually Valery did raise good point, that for IKE this might cause >> issues. >> >> Now when I am thinking about this, I think that for IKE packets the >> response to the IKE request should go to the same TCP session where >> the request came in. This would be aligned with the RFC7296 which says >> you reverse ip-addresses and ports for incoming IKE request, and reply >> to that address. > > That makes sense. > >> For new requests the IKE should use the same TCP session than what is >> being used for ESP, i.e., the most fresh one. >> >> The most fresh should then be defined as the one which has received >> ESP sequence number which is not out of order (note, that there might >> be multipe ESP SAs in the same TCP connection, so largest sequence >> number is not right way to express this), or which has received new >> IKE request (note, not IKE respose, or retrasmitted request) last. > > It doesn't really help to prevent attack, but unnecessary complicates implementations. > I'd rather suggest to choose the TCP connection over which the latest > valid ESP or IKE packet (that is not a retransmission) is received. Right, so how about we say that a packet that causes the responder to choose which TCP connection to use must be: - A valid IKE or ESP message that can be successfully decrypted and authenticated - Not a retransmission - Not outside of the ESP replay window - In order for the sequence of message IDs for that SA Does that work to sufficiently be conservative about which packets to trust, while not adding undue complication? Thanks, Tommy > > In most cases this is equivalent to the rules you suggests > (since TCP prevents reordering the latest packet will have > the highest SN/MID). In case of powerful attacker on the path, > who can steal, drop, modify and replay packets, the rules > you suggest won't help anyway. > > Regards, > Valery. > From nobody Mon Jan 23 04:07:34 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 923FC129B15 for ; Mon, 23 Jan 2017 04:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 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=3.599, 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 dv00dVNsbS9R for ; Mon, 23 Jan 2017 04:07:31 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A91F1295DE for ; Mon, 23 Jan 2017 04:07:31 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id x1so5552931lff.0 for ; Mon, 23 Jan 2017 04:07:31 -0800 (PST) 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=C0li4+bWtargwNKLyPX4OQdiiVxspR3j3cvOVWLVZnA=; b=VWu+rkW22lwzowcvzlp672gNhOeV57Hk96MNOJH73doXzcR7Wg2W+JiAJLAMHBNl3Q SS15Ll4c+6n3fxWea4n7k1DKyfg3jseqe9pNoq+UM4RJoiRAGpI0Jnb64AzV2nN6wR48 QVKSNIZBN1dHXY2/+iZVdaFw4UEMrQJT+3ENGQpNfy+lw8zYypzwau+hH5IBG40rKKHO Jy/jeJw4u/xPaHnVzzP2KuN9VFl0nIxAlZ2XqdKzWa5Vx4q54EGDIjT30tr0p0fHtoet tRYI7dHdcmEumb+8M1CMKYZwWFBjbVXq239i4p9OLxSPGK8aI+W+HrKv1Usqf16XQKUC 6Qnw== 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=C0li4+bWtargwNKLyPX4OQdiiVxspR3j3cvOVWLVZnA=; b=LND2HIwcdG6BIgKQxsOpzGUpHuIMfTWEqRKcPT0P0ETxnuYBhJBVO/xYvgPeGuoseG 9lN9My/zNwitCFvCggGb47nyWGnDQQxtJ+R07D73kBcm2JaDu6koOn+hTHpaY6W1LYJC QIBvKCyGipEy7HGdMLRFjyTmh6JgS9Wo/qy4jQToqB6GcE/YpRToEN5xOLeMfk9ZAhtT FXZfmrCtOvvCkkSp1RrmeLxqzn/TyxHngFgJfyykbbzfkuGqOqUq0aho7j2/8XqCwlkY 3cyyoSgc3xf9FPzM/t0NaGm67n8ivXUZgdlnaF7YOP0kwFrmhKh3szN/6xlUmPZQF/kF eMVA== X-Gm-Message-State: AIkVDXJ9hs379XQbaIgDaAVNwJJ9j/ZpgdRM7eT4iVTBtxU1bhZ7VCBBjDiOgNGqjxpRGg== X-Received: by 10.46.72.10 with SMTP id v10mr11874869lja.46.1485173249425; Mon, 23 Jan 2017 04:07:29 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id s6sm5551456ljd.6.2017.01.23.04.07.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 Jan 2017 04:07:28 -0800 (PST) From: "Valery Smyslov" To: References: <22646.18786.629023.688752@fireball.acr.fi> <22648.48459.686427.557564@fireball.acr.fi> <068a01d272f1$7a1a6280$6e4f2780$@gmail.com> <1C45F99E-A4E0-421F-837E-5BE2F825F9FD@apple.com> In-Reply-To: <1C45F99E-A4E0-421F-837E-5BE2F825F9FD@apple.com> Date: Mon, 23 Jan 2017 15:07:28 +0300 Message-ID: <079101d27571$4468f890$cd3ae9b0$@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: AQCkxeybEg8DzyV7FTOC0kNdz/A/IAHrtaY8AixlbgwCY2cTUgLfCHMPo1Y/y6A= Content-Language: ru Archived-At: Cc: ipsec@ietf.org, 'Tero Kivinen' Subject: Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 12:07:32 -0000 Hi Tommy, > >> Actually Valery did raise good point, that for IKE this might cause > >> issues. > >> > >> Now when I am thinking about this, I think that for IKE packets the > >> response to the IKE request should go to the same TCP session where > >> the request came in. This would be aligned with the RFC7296 which says > >> you reverse ip-addresses and ports for incoming IKE request, and reply > >> to that address. > > > > That makes sense. > > > >> For new requests the IKE should use the same TCP session than what is > >> being used for ESP, i.e., the most fresh one. > >> > >> The most fresh should then be defined as the one which has received > >> ESP sequence number which is not out of order (note, that there might > >> be multipe ESP SAs in the same TCP connection, so largest sequence > >> number is not right way to express this), or which has received new > >> IKE request (note, not IKE respose, or retrasmitted request) last. > > > > It doesn't really help to prevent attack, but unnecessary complicates implementations. > > I'd rather suggest to choose the TCP connection over which the latest > > valid ESP or IKE packet (that is not a retransmission) is received. > > Right, so how about we say that a packet that causes the responder to choose which TCP connection to > use must be: > - A valid IKE or ESP message that can be successfully decrypted and authenticated > - Not a retransmission > - Not outside of the ESP replay window Technically this requirement is wrong, since every ESP packet with SN greater than the highest seen so far will be outside ESP replay window (and will update this window if the packet is decrypted and verified successfully). > - In order for the sequence of message IDs for that SA > > Does that work to sufficiently be conservative about which packets to trust, while not adding undue > complication? I think that it is enough if this is a valid (one that passed a replay check, then successfully decrypted and authenticated) ESP packet or IKE message that is most recently received. This rule would avoid all complexities concerned with determining the highest SN for many ESP connections over single TCP. In normal cases (no attack) the most recently received ESP packet will always have the highest SN if TCP encapsulation is employed. In case of attack that Tero described the attacker must be on the path and there is no defense against she anyway, so no need to complicate the responder. It is also a good thing to advise, that for TCP encapsulation ESP replay window size should be set to 0 (since TCP doesn't allow reordered packets). Regards, Valery. > Thanks, > Tommy > > > > > In most cases this is equivalent to the rules you suggests > > (since TCP prevents reordering the latest packet will have > > the highest SN/MID). In case of powerful attacker on the path, > > who can steal, drop, modify and replay packets, the rules > > you suggest won't help anyway. > > > > Regards, > > Valery. > > From nobody Mon Jan 23 13:59:45 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 94F8D129963; Mon, 23 Jan 2017 13:59:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148520877960.29570.5105705480504590661.idtracker@ietfa.amsl.com> Date: Mon, 23 Jan 2017 13:59:39 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 21:59:39 -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 : TCP Encapsulation of IKE and IPsec Packets Authors : Tommy Pauly Samy Touati Ravi Mantha Filename : draft-ietf-ipsecme-tcp-encaps-05.txt Pages : 21 Date : 2017-01-23 Abstract: This document describes a method to transport IKE and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as TCP encapsulation, involves sending both IKE packets for tunnel establishment as well as tunneled packets using ESP over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 23 17:06:48 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 2B8F01294DF for ; Mon, 23 Jan 2017 17:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.656 X-Spam-Level: X-Spam-Status: No, score=-8.656 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, RCVD_IN_MSPIKE_H2=-1.156, RP_MATCHES_RCVD=-3.199, 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 21o87VODBKs2 for ; Mon, 23 Jan 2017 17:06:45 -0800 (PST) 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 C1B8A1293DF for ; Mon, 23 Jan 2017 17:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1485220005; 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=Am3aX9ID+KMBn4u1f2wiz9yPqlar0lmOvNlL1J0+Ouk=; b=ynBkF22mlWO5I54lKB/vscZyY7V/Nv8muNx1Re6VEnZmtaLSHk1Fkcq+EG2tHiyT kdTC3xTL5Oxhr+9X/OP184hojrUwVoOd8dOWyZAAYeAOC63BS/c3Nah6qus7jidV lUgixxk4ZKdZ8p8qifzUrinVWJq5NbUAW03e5zmK4pjWeP2uTCMGtmUFd2x2UAxI DG8LR2ZrBpZtPNf+xLRsE244dySfhgmB8jonTFbpDORtpHSpeCNB+hQdybAViw+Y H+ZKkA2gPlmbip3gpTpHPVUHLYhGHlH88F2aqvxurlXv9GAjH+HSSecBBmMCjXTC JW6vm9BtWPyV74UFyJiRpQ==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 14.C6.05063.5A8A6885; Mon, 23 Jan 2017 17:06:45 -0800 (PST) X-AuditID: 11973e16-99e949a0000013c7-11-5886a8a58102 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by relay5.apple.com (Apple SCV relay) with SMTP id F9.49.27929.5A8A6885; Mon, 23 Jan 2017 17:06:45 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.226.23.83] (unknown [17.226.23.83]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OK900HWNF313Z30@nwk-mmpp-sz13.apple.com>; Mon, 23 Jan 2017 17:06:45 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Date: Mon, 23 Jan 2017 17:06:37 -0800 References: <148520877960.29570.5105705480504590661.idtracker@ietfa.amsl.com> To: IPsecME WG , Tero Kivinen , Valery Smyslov In-reply-to: <148520877960.29570.5105705480504590661.idtracker@ietfa.amsl.com> Message-id: <25376ABE-ACCD-449C-9604-E8745069802C@apple.com> X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUi2FAYobt0RVuEwa4nChb7t7xgszh6/jmb xY0PM9kcmD12zrrL7rFkyU8mj8NfF7IEMEdx2aSk5mSWpRbp2yVwZbxrvMZesEegomm6UwPj eZ4uRk4OCQETiQNN79m6GLk4hAT2MkqcbZ3JDJO4OHUWE0TiEKPEoeVNrCAJXgFBiR+T77F0 MXJwMAvISxw8LwsSZhbQkvj+qJUFor6DSWL98zNgNcICEhKb9ySC1LAJqEgc/7YBbL6wgJlE 9/IPjCA2i4CqxNuzF1hAbCEBX4nD11aDrRIRSJaY3fiTDcTmFPCTuLH3FBPECTYSN/4vZIe4 U1aie+E0ZpC9EgI72CSeLNvJMoFRaBaSU2chnDoLyakLGJlXMQrlJmbm6GbmmeslFhTkpOol 5+duYgSF9HQ7sR2MD1dZHWIU4GBU4uE9IdMWIcSaWFZcmXuIUZqDRUmc90wVUEggPbEkNTs1 tSC1KL6oNCe1+BAjEwenVAOj4NyJtzLfzzLXSM4W3ivg/6J16x45g0PTDBYeMrtQdmqBRcWX paaqwuxd4QueLlP58IK9LWR17ZPP4V9YJqXeYmlVlb/w5+3zH0/nyKz4+fXw5FfiFefd+PgY nafer754Pb9+ia1z8etHXGI7D86cvWJTis3mhMmvFX9dmL5Z4Zl4vsQ9e3tmeSWW4oxEQy3m ouJEAIY9Ty5KAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUi2FB8Q3fpirYIg5//BC32b3nBZnH0/HM2 ixsfZrI5MHvsnHWX3WPJkp9MHoe/LmQJYI7isklJzcksSy3St0vgynjXeI29YI9ARdN0pwbG 8zxdjJwcEgImEhenzmKCsMUkLtxbz9bFyMUhJHCIUeLQ8iZWkASvgKDEj8n3WLoYOTiYBeQl Dp6XBQkzC2hJfH/UygJR38Eksf75GbAaYQEJic17EkFq2ARUJI5/28AMYgsLmEl0L//ACGKz CKhKvD17gQXEFhLwlTh8bTXYKhGBZInZjT/ZQGxOAT+JG3tPMUGcYCNx4/9Cdog7ZSW6F05j nsAoMAvJdbMQrpuF5LoFjMyrGAWKUnMSK031EgsKclL1kvNzNzGCQ7MwYgfj/2VWhxgFOBiV eHgLpNoihFgTy4orc4He52BWEuHlXggU4k1JrKxKLcqPLyrNSS0+xJgMdP9EZinR5Hxg3OSV xBuamBiYGBubGRubm5iTJqwkzpvU3RIhJJCeWJKanZpakFoEs4WJg1OqgTHad/HvVtvr5VNF b0T1lP9jj7gZu1sqWH7hqmm/Nzu+cd7lZrT2z+QKUbZni79E8l3dH3NgVvjTHcwWTYZhR9Xq ku5e2D0zcrGruUz3astJfiLn1m/Ltc584B6QqnJFTcVr0wO3yLhXHnyRBrfLD1hIbe8qWtSZ 0DN5nWAoS8eWkP5JCyfdSVNiKc5INNRiLipOBABD5w4dkQIAAA== Archived-At: Subject: [IPsec] New version: draft-ietf-ipsecme-tcp-encaps-05 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 01:06:47 -0000 Hello, I've uploaded a new version of the TCP Encapsulation draft that is in WG last call, incorporating the feedback from Tero and Valery. Please take another read through, and let me know your feedback and if you think we want any more changes to the document. Thanks! Tommy > On Jan 23, 2017, at 1:59 PM, internet-drafts@ietf.org wrote: > > > 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 : TCP Encapsulation of IKE and IPsec Packets > Authors : Tommy Pauly > Samy Touati > Ravi Mantha > Filename : draft-ietf-ipsecme-tcp-encaps-05.txt > Pages : 21 > Date : 2017-01-23 > > Abstract: > This document describes a method to transport IKE and IPsec packets > over a TCP connection for traversing network middleboxes that may > block IKE negotiation over UDP. This method, referred to as TCP > encapsulation, involves sending both IKE packets for tunnel > establishment as well as tunneled packets using ESP over a TCP > connection. This method is intended to be used as a fallback option > when IKE cannot be negotiated over UDP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Jan 30 12:54: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 7D92D129BCA for ; Mon, 30 Jan 2017 12:54:54 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYyQ5X4Ucdra for ; Mon, 30 Jan 2017 12:54:52 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0113.outbound.protection.outlook.com [23.103.200.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4595D1295BA for ; Mon, 30 Jan 2017 12:54:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ccLL+pwmh2iwwaOH7fbbR5lKgJu8iYX2K//s8MP54ww=; b=MRQMk7ap6ijvitM/0qXeSnBzmgDaRtaTJbMIi6scsfg1aHptS5/UecHveNOS5/0HKVEIwQ1qJgYwif+6Um1taez65b0BUZzX4YQ/VBrwubfx71xXfNR/zIUn7v+0q3msChkNE9SrLvbRf+VUGKR+7ubrV+M9ckVwOlfpXad14Bo= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1437.namprd09.prod.outlook.com (10.173.50.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Mon, 30 Jan 2017 20:54:50 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0874.019; Mon, 30 Jan 2017 20:54:50 +0000 From: "Waltermire, David A. (Fed)" To: Tero Kivinen , Timothy Carlin Thread-Topic: [IPsec] Review of draft-ietf-ipsecme-rfc7321bis-01 Thread-Index: AQHSbNQzyQY38foTKUiMwW01S9qRvqFRmsbg Date: Mon, 30 Jan 2017 20:54:50 +0000 Message-ID: References: <22647.32368.596076.881346@fireball.acr.fi> In-Reply-To: <22647.32368.596076.881346@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: 3a46db94-9a8c-4bb7-a159-08d449523bf5 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR09MB1437; x-microsoft-exchange-diagnostics: 1; MWHPR09MB1437; 7:X50H3ZxAE6hEQqHWQbvxZha6H/MxqeA4Ak8kWx7QdE4Zdj0Cq0bfbwFq9l9EOpjN5ptH5VaAXYuWv+5gRbFyj6VJBzoG4O9WKVOxA9qKhNV/a3exHadx+hrgsvF7nktRWEWIpL+UP3niEurmJZFnFa+WRHsuHGwPVO2+EQKz9rNJkeifzSMaSBJVJshnc53IY/K/TKJ0Qo0H51Qhxv6CoFgFPvShlTeIDAMJvVz2XgTKmIX68POGBA/SHQU820Iz2LGxPJnmFM31NYd69vPOQG3DV30FD3MnlHouYrxZOvi+stS7EB8Oegmirbu4GW3fUQEc49rooz5NQCLA4KjcO9iCDzRabhl90zXc+VCOv1hzbJKoWbv2xT521YAYVR1ItBcEseGRvLaP9Q7HFwWAs0bP/jDaqHXm5yfR+MoAEJKtMun7WnZwdkjCtqfpivlayuEHJ9UC2SaHVKAyT+weCg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:MWHPR09MB1437; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1437; x-forefront-prvs: 0203C93D51 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39410400002)(39850400002)(39860400002)(377454003)(189002)(199003)(13464003)(76176999)(33656002)(2950100002)(8936002)(7696004)(3660700001)(8676002)(81166006)(5660300001)(106116001)(122556002)(50986999)(54356999)(2171001)(38730400001)(77096006)(105586002)(25786008)(229853002)(6436002)(101416001)(106356001)(99286003)(6506006)(55016002)(2900100001)(81156014)(92566002)(6306002)(9686003)(2906002)(66066001)(4326007)(53936002)(3280700002)(102836003)(3846002)(230783001)(5001770100001)(305945005)(7736002)(189998001)(97736004)(68736007)(86362001)(74316002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1437; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2017 20:54:50.5459 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1437 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Review of draft-ietf-ipsecme-rfc7321bis-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 20:54:54 -0000 >From what I can tell, addressing this feedback is the only thing that needs= to be done before progressing this draft to the IESG for publication. Tim, Did Tero's response address your concerns? Tero, Are you or the other authors planning to post an update based on this feedb= ack? Thanks, Dave > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen > Sent: Thursday, January 12, 2017 8:03 AM > To: Timothy Carlin > Cc: ipsec@ietf.org > Subject: [IPsec] Review of draft-ietf-ipsecme-rfc7321bis-01 >=20 > Timothy Carlin writes: > > My comments: > > > > * Section 4 mentions that that 256-bit keys are raised to the SHOULD > > level. Should this read as these are now the MUST level as > > ENCR_AES_CBC and > > ENCR_AES_GCM_16 are at the MUST level according to Table 1 (with the > > [1] endnote)? >=20 > Yes, I think this is inconsistancy caused by last edits, i.e., when we ch= anged > the 256-bit keys to MUST, we only edited the footnote, and missed the tex= t > in section 4. >=20 > So correct change is: >=20 > OLD: >=20 > In that sense 256 bit keys > status has been raised from MAY in RFC7321 to SHOULD. >=20 > NEW: >=20 > In that sense 256 bit keys > status has been raised from MAY in RFC7321 to MUST. >=20 > > * Section 5 mentions ENCR_NULL_AUTH_AES_GMAC, which is not > referenced > > anywhere in the document.=A0 Should it be added to Table 1 at the MUST > > level? >=20 > No. It is MAY level algorithm, just like the AUTH_AES_128_GMAC and > AUTH_AES_256_GMAC algorithms. The reason those > AUTH_AES_{128,256}_GMAC algorithms are listed here is, that they used to > be SHOULD+, and are now downgraded to MAY. >=20 > The ENCR_NULL_AUTH_AES_GMAC has been MAY, and will be MAY, so it is > not mentioned in the section 4. >=20 > Your text edits seemed to be fine. > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Jan 30 12: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 68D441295F2 for ; Mon, 30 Jan 2017 12:59:41 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8Y2DaVNFM4I for ; Mon, 30 Jan 2017 12:59:39 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0129.outbound.protection.outlook.com [23.103.200.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3020E1295F3 for ; Mon, 30 Jan 2017 12:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HXJQrlZq6n9vGriZLKRu4JeNZR8ev7cz1PtL2AiF8Xg=; b=H7/ZE3L81qUxpV6wmh7zNE3gleUxbBLfYrSJfSX3wOIvby7uUF8ixj8ei6c+E+VZc/VJoxQzYQmAQCXD0cDYIA6Ye/sG27sSA8Fnf/SXOiCg+V+OLJ5iOCQTydO1f7ZE6VMgeUy8meDe02L3AJgJrxB8cNEZY1aIbi/ZEHJxDGY= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1437.namprd09.prod.outlook.com (10.173.50.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Mon, 30 Jan 2017 20:59:37 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0874.019; Mon, 30 Jan 2017 20:59:37 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: Call for adoption of draft-pauly-ipsecme-split-dns as an IPSecME WG document Thread-Index: AdJ7O2aEA72b495dQvCh+t+j4s7dJQ== Date: Mon, 30 Jan 2017 20:59:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: d172e8e8-bf71-4154-4933-08d44952e719 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR09MB1437; x-microsoft-exchange-diagnostics: 1; MWHPR09MB1437; 7:HiCn57Mzl9lP/zWnBcdcc5kwBu1qSs74kY8ZsQGFm/z91H21fG1hkvbxhAV5DUwEHmVyWgY0+3yK+qNHQIa9tcFhyJtQH4H0jyLkvFeWbWBaTuTSQtLte+eySPHBVIydes3Fja1wcVx+/3ku+VMi6Q1Fs/qk63BiSSG4MHSXV9+rO7boXskwyazLugg5IwnS7ZV05F9QRJQsh8LdlTdqvhOS7Kf15T7QkX0iblCG8XgoAAfkOd7eY4rdvlTrA29AFX7/7GnQbunMCFWSPC5MeowqTgREq8WslG4oFY+3JZLO3C7SqPOOz96qkdYq0mr5sFhJgTaqtwb8T0Obrx1G6UKjjElRH1wTp3SfVCIMegkcYs3/xtJbpQ/cIklxKHUDnYdsjMi86fp5bA6tpy/4JHP06LlfhMNXMzsfibLQBlArQ4GBb8KdVCtnbVMUNB9d85xS29k4ww6C7ssVsnA63w== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:MWHPR09MB1437; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1437; x-forefront-prvs: 0203C93D51 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39410400002)(39850400002)(39860400002)(189002)(199003)(33656002)(450100001)(110136003)(8936002)(7696004)(3660700001)(6916009)(8676002)(81166006)(5660300001)(122556002)(50986999)(54356999)(38730400001)(77096006)(105586002)(25786008)(6436002)(101416001)(106356001)(99286003)(6506006)(55016002)(2900100001)(81156014)(92566002)(6306002)(9686003)(2906002)(66066001)(53936002)(107886002)(3280700002)(102836003)(3846002)(230783001)(305945005)(7736002)(189998001)(97736004)(68736007)(86362001)(74316002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1437; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2017 20:59:37.7881 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1437 Archived-At: Subject: [IPsec] Call for adoption of draft-pauly-ipsecme-split-dns as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 20:59:41 -0000 This is the call for adoption of https://datatracker.ietf.org/doc/draft-pau= ly-ipsecme-split-dns/ as an IPSecME working group (WG) document.=20 By adopting this draft, the WG is agreeing to take this on as an official W= G item to continue work on the draft. Please reply to this message with any= comments supporting or concerns against adopting this draft. This call wil= l run until Friday, February 10th, 2017 UTC 23:59. Thanks, Dave and Tero From nobody Mon Jan 30 13:00:31 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 D288B129580; Mon, 30 Jan 2017 13:00:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148581002982.29828.4148867564721628326.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2017 13:00:29 -0800 Archived-At: Subject: [IPsec] The IPSECME WG has placed draft-pauly-ipsecme-split-dns in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 21:00:30 -0000 The IPSECME WG has placed draft-pauly-ipsecme-split-dns in state Call For Adoption By WG Issued (entered by David Waltermire) The document is available at https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/ From nobody Mon Jan 30 13:05: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 43DF01295DF for ; Mon, 30 Jan 2017 13:05:43 -0800 (PST) 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, 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 (1024-bit key) header.d=iol.unh.edu 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 bNF2l5T7hDy0 for ; Mon, 30 Jan 2017 13:05:35 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 EFDA0129606 for ; Mon, 30 Jan 2017 13:05:34 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id y9so260885404uae.2 for ; Mon, 30 Jan 2017 13:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dQMHOuELBvje7RNGW/HRi/pd34Q9C9kKsOAYJO9dx9s=; b=Fh4gibR0ffsEjNJ/NJbtQZFijiGMZimS1R/8vBj4ZTH2R8sE+7HKDl4/rEm2U0TiCL WOqSEZpAFZtsv7ZLTc296Eouykp9IDLlurptQIU29C6IrWi+YXQmERt0vqTniEUHE8FG GD8RaahqglUbtVo7VWh6l+iCJckCNdfSe66BQ= 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=dQMHOuELBvje7RNGW/HRi/pd34Q9C9kKsOAYJO9dx9s=; b=FOTydl6neO8W7KEjflJL4kMYFssQXyeXJ1j51Hy6DB/dAzp0wP/cQpl4QnQxMwBf24 UaLr1eXrfUxUiyyFlDWr3PrlRbpCHo9tKHupkYhkJ2m0nKvXWT9TBUK7BV0c63fezFmU 3d4h1zbW0XVaTcdUiLk6eRIsyOvPDIkkMfXB67loamoKmHUss6kRsBG4kJsxxGaYcD6H g5uIZaw7TQHqSEIUcN9OnFiD99u2YtdftZU+SvR+ocNLtgFlXRJZ+5v3fhnot9V+rfTd qz7/+AyuVCuoppTQ36DBADVS0aR5+F9pH7ENqb93ETfkAFyQEYF2clsuQhgHxDYrB07l KnZw== X-Gm-Message-State: AIkVDXIROADMf2tmgOIHZCd6B7i7IUP6JZIFew5+zQdQW8a3YjXsYB++WgnG2hMOyffM8VXjcN8kwzvL2gs7C/bg X-Received: by 10.176.84.210 with SMTP id q18mr10417168uaa.35.1485810334034; Mon, 30 Jan 2017 13:05:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.48.196 with HTTP; Mon, 30 Jan 2017 13:04:53 -0800 (PST) In-Reply-To: References: <22647.32368.596076.881346@fireball.acr.fi> From: Timothy Carlin Date: Mon, 30 Jan 2017 16:04:53 -0500 Message-ID: To: "Waltermire, David A. (Fed)" Content-Type: multipart/alternative; boundary=f403045e22222a37f30547562d1c Archived-At: Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] Review of draft-ietf-ipsecme-rfc7321bis-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 21:05:43 -0000 --f403045e22222a37f30547562d1c Content-Type: text/plain; charset=UTF-8 Hi Dave, Yes, I believe they have been addressed. Thanks for checking in, my apologies for not confirming sooner. Best Regards, Tim Carlin On Mon, Jan 30, 2017 at 3:54 PM, Waltermire, David A. (Fed) < david.waltermire@nist.gov> wrote: > >From what I can tell, addressing this feedback is the only thing that > needs to be done before progressing this draft to the IESG for publication. > > Tim, > > Did Tero's response address your concerns? > > Tero, > > Are you or the other authors planning to post an update based on this > feedback? > > Thanks, > Dave > > > -----Original Message----- > > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen > > Sent: Thursday, January 12, 2017 8:03 AM > > To: Timothy Carlin > > Cc: ipsec@ietf.org > > Subject: [IPsec] Review of draft-ietf-ipsecme-rfc7321bis-01 > > > > Timothy Carlin writes: > > > My comments: > > > > > > * Section 4 mentions that that 256-bit keys are raised to the SHOULD > > > level. Should this read as these are now the MUST level as > > > ENCR_AES_CBC and > > > ENCR_AES_GCM_16 are at the MUST level according to Table 1 (with the > > > [1] endnote)? > > > > Yes, I think this is inconsistancy caused by last edits, i.e., when we > changed > > the 256-bit keys to MUST, we only edited the footnote, and missed the > text > > in section 4. > > > > So correct change is: > > > > OLD: > > > > In that sense 256 bit keys > > status has been raised from MAY in RFC7321 to SHOULD. > > > > NEW: > > > > In that sense 256 bit keys > > status has been raised from MAY in RFC7321 to MUST. > > > > > * Section 5 mentions ENCR_NULL_AUTH_AES_GMAC, which is not > > referenced > > > anywhere in the document. Should it be added to Table 1 at the MUST > > > level? > > > > No. It is MAY level algorithm, just like the AUTH_AES_128_GMAC and > > AUTH_AES_256_GMAC algorithms. The reason those > > AUTH_AES_{128,256}_GMAC algorithms are listed here is, that they used to > > be SHOULD+, and are now downgraded to MAY. > > > > The ENCR_NULL_AUTH_AES_GMAC has been MAY, and will be MAY, so it is > > not mentioned in the section 4. > > > > Your text edits seemed to be fine. > > -- > > kivinen@iki.fi > > > > _______________________________________________ > > 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 > --f403045e22222a37f30547562d1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dave,

Yes, I believe they have been = addressed.=C2=A0 Thanks for checking in, my apologies for not confirming so= oner.

Best Regards,
Tim Carlin

On Mon, Jan 30, 2017 at 3:54 PM, W= altermire, David A. (Fed) <david.waltermire@nist.gov> wrote:
>From what I can tell, addres= sing this feedback is the only thing that needs to be done before progressi= ng this draft to the IESG for publication.

Tim,

Did Tero's response address your concerns?

Tero,

Are you or the other authors planning to post an update based on this feedb= ack?

Thanks,
Dave

> -----Original Message-----
> From: IPsec [mailto:ipsec-bo= unces@ietf.org] On Behalf Of Tero Kivinen
> Sent: Thursday, January 12, 2017 8:03 AM
> To: Timothy Carlin <tjcarli= n@iol.unh.edu>
> Cc: ipsec@ietf.org
> Subject: [IPsec] Review of draft-ietf-ipsecme-rfc7321bis-01
>
> Timothy Carlin writes:
> > My comments:
> >
> > * Section 4 mentions that that 256-bit keys are raised to the SHO= ULD
> > level. Should this read as these are now the MUST level as
> > ENCR_AES_CBC and
> > ENCR_AES_GCM_16 are at the MUST level according to Table 1 (with = the
> > [1] endnote)?
>
> Yes, I think this is inconsistancy caused by last edits, i.e., when we= changed
> the 256-bit keys to MUST, we only edited the footnote, and missed the = text
> in section 4.
>
> So correct change is:
>
> OLD:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In that sense 25= 6 bit keys
>=C2=A0 =C2=A0 status has been raised from MAY in RFC7321 to SHOULD.
>
> NEW:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In that sense 25= 6 bit keys
>=C2=A0 =C2=A0 status has been raised from MAY in RFC7321 to MUST.
>
> > * Section 5 mentions ENCR_NULL_AUTH_AES_GMAC, which is not
> referenced
> > anywhere in the document.=C2=A0 Should it be added to Table 1 at = the MUST
> > level?
>
> No. It is MAY level algorithm, just like the AUTH_AES_128_GMAC and
> AUTH_AES_256_GMAC algorithms. The reason those
> AUTH_AES_{128,256}_GMAC algorithms are listed here is, that they used = to
> be SHOULD+, and are now downgraded to MAY.
>
> The ENCR_NULL_AUTH_AES_GMAC has been MAY, and will be MAY, so it is > not mentioned in the section 4.
>
> Your text edits seemed to be fine.
> --
> kivinen@iki.fi
>
> _______________________________________________
> 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

--f403045e22222a37f30547562d1c-- From nobody Mon Jan 30 13:33: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 94B0112960A for ; Mon, 30 Jan 2017 13:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 987iB1qXekaL for ; Mon, 30 Jan 2017 13:33:53 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0108.outbound.protection.outlook.com [23.103.200.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00041295F9 for ; Mon, 30 Jan 2017 13:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AvPTVMswM3rTYcmY85AYsryXh/Q3f7w6DbcgxQdpk2c=; b=bUdeopTVVIv7u/4TDFn5Gf3VPF9zm08FXltBMePWDH4BmgLW6MMXXVHJy18Tfn8zScY3saynDWEG3GgCCVPqASpwn1utcxEYiIcxJ4bGJmTmVUFZU//tPZvF8djkX3VY37sSpZMrQt5jZKQq4UoyPzaGx2ZN7qJxXIfh1k9Nyzk= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1439.namprd09.prod.outlook.com (10.173.50.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Mon, 30 Jan 2017 21:33:52 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0874.019; Mon, 30 Jan 2017 21:33:52 +0000 From: "Waltermire, David A. (Fed)" To: Timothy Carlin Thread-Topic: [IPsec] Review of draft-ietf-ipsecme-rfc7321bis-01 Thread-Index: AQHSezyaMSdRzg6DKEq5V1q+9uTVm6FRingw Date: Mon, 30 Jan 2017 21:33:51 +0000 Message-ID: References: <22647.32368.596076.881346@fireball.acr.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: 2154d23d-49b6-44e0-e120-08d44957af9a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR09MB1439; x-microsoft-exchange-diagnostics: 1; MWHPR09MB1439; 7:POn2LxE2kQCeSgHKYhv0A4g6GMV3Pfb0E5897or3X7qBZNouvBH45VOsiiAWwcY5DAotbzA/mW3i8H2L4/SNhq3CZVhmCIjdzRlQ4wTX2Nu8CAAaJgMlFewenrHSem42+1n8P7MVCcHE0LBPhlxUtDDCFjWTDV1s2n6KPy7hle+NIWvk10SFBFJBaIh62WLr89DBOsGnTQulXg9yo7/Adn070TysEMtn+cyC08TIFyw8jAee/eNhrF1pk7W6t6qMaPXAZ1SurBrVNRE/Jc/3yM0EQlfczTEZ/1sGN5QhhkSnveRHO/8m5NHfEElV4yP0kfKk0CeIYWlN01ZmdTrp3eCj5QUWhSDJkdMBD8bBmGe6Xs72uVQz0OQned0RXjlfPnvc5Ujj02DqFNxLKwstEBkwIUe0SrfKsPDeycbzdm3oSYEKKhLMSuyXEGzi6qC0Wz6qvpTOgl+CiJns8AxYVg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:MWHPR09MB1439; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1439; x-forefront-prvs: 0203C93D51 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39860400002)(39850400002)(39410400002)(39450400003)(189002)(24454002)(51914003)(199003)(13464003)(377454003)(3280700002)(2900100001)(92566002)(53936002)(230783001)(74316002)(93886004)(3660700001)(101416001)(7736002)(7906003)(19609705001)(236005)(2906002)(8936002)(4326007)(9686003)(3846002)(6116002)(790700001)(102836003)(81166006)(81156014)(106116001)(105586002)(86362001)(229853002)(106356001)(2950100002)(6916009)(66066001)(7696004)(6506006)(68736007)(8676002)(38730400001)(6436002)(97736004)(54896002)(606005)(99286003)(55016002)(54906002)(77096006)(76176999)(110136003)(122556002)(54356999)(2171001)(33656002)(5660300001)(50986999)(6306002)(189998001)(25786008); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1439; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR09MB14404376A0CEC3627AA16A45F04B0MWHPR09MB1440namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2017 21:33:51.9685 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1439 Archived-At: Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] Review of draft-ietf-ipsecme-rfc7321bis-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 21:33:56 -0000 --_000_MWHPR09MB14404376A0CEC3627AA16A45F04B0MWHPR09MB1440namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IGEgcHJvYmxlbS4gVGhhbmtzIGZvciB0aGUgZmVlZGJhY2shDQoNCkRhdmUNCg0KRnJvbTog VGltb3RoeSBDYXJsaW4gW21haWx0bzp0amNhcmxpbkBpb2wudW5oLmVkdV0NClNlbnQ6IE1vbmRh eSwgSmFudWFyeSAzMCwgMjAxNyA0OjA1IFBNDQpUbzogV2FsdGVybWlyZSwgRGF2aWQgQS4gKEZl ZCkgPGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y+DQpDYzogVGVybyBLaXZpbmVuIDxraXZpbmVu QGlraS5maT47IGlwc2VjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0lQc2VjXSBSZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1pcHNlY21lLXJmYzczMjFiaXMtMDENCg0KSGkgRGF2ZSwNCg0KWWVzLCBJIGJl bGlldmUgdGhleSBoYXZlIGJlZW4gYWRkcmVzc2VkLiAgVGhhbmtzIGZvciBjaGVja2luZyBpbiwg bXkgYXBvbG9naWVzIGZvciBub3QgY29uZmlybWluZyBzb29uZXIuDQoNCkJlc3QgUmVnYXJkcywN ClRpbSBDYXJsaW4NCg0KT24gTW9uLCBKYW4gMzAsIDIwMTcgYXQgMzo1NCBQTSwgV2FsdGVybWly ZSwgRGF2aWQgQS4gKEZlZCkgPGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y8bWFpbHRvOmRhdmlk LndhbHRlcm1pcmVAbmlzdC5nb3Y+PiB3cm90ZToNCj5Gcm9tIHdoYXQgSSBjYW4gdGVsbCwgYWRk cmVzc2luZyB0aGlzIGZlZWRiYWNrIGlzIHRoZSBvbmx5IHRoaW5nIHRoYXQgbmVlZHMgdG8gYmUg ZG9uZSBiZWZvcmUgcHJvZ3Jlc3NpbmcgdGhpcyBkcmFmdCB0byB0aGUgSUVTRyBmb3IgcHVibGlj YXRpb24uDQoNClRpbSwNCg0KRGlkIFRlcm8ncyByZXNwb25zZSBhZGRyZXNzIHlvdXIgY29uY2Vy bnM/DQoNClRlcm8sDQoNCkFyZSB5b3Ugb3IgdGhlIG90aGVyIGF1dGhvcnMgcGxhbm5pbmcgdG8g cG9zdCBhbiB1cGRhdGUgYmFzZWQgb24gdGhpcyBmZWVkYmFjaz8NCg0KVGhhbmtzLA0KRGF2ZQ0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IElQc2VjIFttYWlsdG86aXBz ZWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aXBzZWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJl aGFsZiBPZiBUZXJvIEtpdmluZW4NCj4gU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTIsIDIwMTcg ODowMyBBTQ0KPiBUbzogVGltb3RoeSBDYXJsaW4gPHRqY2FybGluQGlvbC51bmguZWR1PG1haWx0 bzp0amNhcmxpbkBpb2wudW5oLmVkdT4+DQo+IENjOiBpcHNlY0BpZXRmLm9yZzxtYWlsdG86aXBz ZWNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFtJUHNlY10gUmV2aWV3IG9mIGRyYWZ0LWlldGYtaXBz ZWNtZS1yZmM3MzIxYmlzLTAxDQo+DQo+IFRpbW90aHkgQ2FybGluIHdyaXRlczoNCj4gPiBNeSBj b21tZW50czoNCj4gPg0KPiA+ICogU2VjdGlvbiA0IG1lbnRpb25zIHRoYXQgdGhhdCAyNTYtYml0 IGtleXMgYXJlIHJhaXNlZCB0byB0aGUgU0hPVUxEDQo+ID4gbGV2ZWwuIFNob3VsZCB0aGlzIHJl YWQgYXMgdGhlc2UgYXJlIG5vdyB0aGUgTVVTVCBsZXZlbCBhcw0KPiA+IEVOQ1JfQUVTX0NCQyBh bmQNCj4gPiBFTkNSX0FFU19HQ01fMTYgYXJlIGF0IHRoZSBNVVNUIGxldmVsIGFjY29yZGluZyB0 byBUYWJsZSAxICh3aXRoIHRoZQ0KPiA+IFsxXSBlbmRub3RlKT8NCj4NCj4gWWVzLCBJIHRoaW5r IHRoaXMgaXMgaW5jb25zaXN0YW5jeSBjYXVzZWQgYnkgbGFzdCBlZGl0cywgaS5lLiwgd2hlbiB3 ZSBjaGFuZ2VkDQo+IHRoZSAyNTYtYml0IGtleXMgdG8gTVVTVCwgd2Ugb25seSBlZGl0ZWQgdGhl IGZvb3Rub3RlLCBhbmQgbWlzc2VkIHRoZSB0ZXh0DQo+IGluIHNlY3Rpb24gNC4NCj4NCj4gU28g Y29ycmVjdCBjaGFuZ2UgaXM6DQo+DQo+IE9MRDoNCj4NCj4gICAgICAgICAgICAgICBJbiB0aGF0 IHNlbnNlIDI1NiBiaXQga2V5cw0KPiAgICBzdGF0dXMgaGFzIGJlZW4gcmFpc2VkIGZyb20gTUFZ IGluIFJGQzczMjEgdG8gU0hPVUxELg0KPg0KPiBORVc6DQo+DQo+ICAgICAgICAgICAgICAgSW4g dGhhdCBzZW5zZSAyNTYgYml0IGtleXMNCj4gICAgc3RhdHVzIGhhcyBiZWVuIHJhaXNlZCBmcm9t IE1BWSBpbiBSRkM3MzIxIHRvIE1VU1QuDQo+DQo+ID4gKiBTZWN0aW9uIDUgbWVudGlvbnMgRU5D Ul9OVUxMX0FVVEhfQUVTX0dNQUMsIHdoaWNoIGlzIG5vdA0KPiByZWZlcmVuY2VkDQo+ID4gYW55 d2hlcmUgaW4gdGhlIGRvY3VtZW50LiAgU2hvdWxkIGl0IGJlIGFkZGVkIHRvIFRhYmxlIDEgYXQg dGhlIE1VU1QNCj4gPiBsZXZlbD8NCj4NCj4gTm8uIEl0IGlzIE1BWSBsZXZlbCBhbGdvcml0aG0s IGp1c3QgbGlrZSB0aGUgQVVUSF9BRVNfMTI4X0dNQUMgYW5kDQo+IEFVVEhfQUVTXzI1Nl9HTUFD IGFsZ29yaXRobXMuIFRoZSByZWFzb24gdGhvc2UNCj4gQVVUSF9BRVNfezEyOCwyNTZ9X0dNQUMg YWxnb3JpdGhtcyBhcmUgbGlzdGVkIGhlcmUgaXMsIHRoYXQgdGhleSB1c2VkIHRvDQo+IGJlIFNI T1VMRCssIGFuZCBhcmUgbm93IGRvd25ncmFkZWQgdG8gTUFZLg0KPg0KPiBUaGUgRU5DUl9OVUxM X0FVVEhfQUVTX0dNQUMgaGFzIGJlZW4gTUFZLCBhbmQgd2lsbCBiZSBNQVksIHNvIGl0IGlzDQo+ IG5vdCBtZW50aW9uZWQgaW4gdGhlIHNlY3Rpb24gNC4NCj4NCj4gWW91ciB0ZXh0IGVkaXRzIHNl ZW1lZCB0byBiZSBmaW5lLg0KPiAtLQ0KPiBraXZpbmVuQGlraS5maTxtYWlsdG86a2l2aW5lbkBp a2kuZmk+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IElQc2VjIG1haWxpbmcgbGlzdA0KPiBJUHNlY0BpZXRmLm9yZzxtYWlsdG86SVBzZWNA aWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklQc2Vj IG1haWxpbmcgbGlzdA0KSVBzZWNAaWV0Zi5vcmc8bWFpbHRvOklQc2VjQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0KDQo= --_000_MWHPR09MB14404376A0CEC3627AA16A45F04B0MWHPR09MB1440namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk5vdCBhIHByb2JsZW0uIFRoYW5rcyBmb3IgdGhlIGZlZWRi YWNrITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5EYXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IFRpbW90aHkgQ2FybGluIFttYWlsdG86dGpjYXJsaW5AaW9s LnVuaC5lZHVdDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKYW51YXJ5IDMwLCAyMDE3IDQ6 MDUgUE08YnI+DQo8Yj5Ubzo8L2I+IFdhbHRlcm1pcmUsIERhdmlkIEEuIChGZWQpICZsdDtkYXZp ZC53YWx0ZXJtaXJlQG5pc3QuZ292Jmd0Ozxicj4NCjxiPkNjOjwvYj4gVGVybyBLaXZpbmVuICZs dDtraXZpbmVuQGlraS5maSZndDs7IGlwc2VjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbSVBzZWNdIFJldmlldyBvZiBkcmFmdC1pZXRmLWlwc2VjbWUtcmZjNzMyMWJpcy0wMTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBE YXZlLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCBJ IGJlbGlldmUgdGhleSBoYXZlIGJlZW4gYWRkcmVzc2VkLiZuYnNwOyBUaGFua3MgZm9yIGNoZWNr aW5nIGluLCBteSBhcG9sb2dpZXMgZm9yIG5vdCBjb25maXJtaW5nIHNvb25lci48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkJlc3QgUmVn YXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRpbSBDYXJsaW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24s IEphbiAzMCwgMjAxNyBhdCAzOjU0IFBNLCBXYWx0ZXJtaXJlLCBEYXZpZCBBLiAoRmVkKSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3YiIHRhcmdldD0iX2JsYW5r Ij5kYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O0Zyb20gd2hhdCBJIGNhbiB0 ZWxsLCBhZGRyZXNzaW5nIHRoaXMgZmVlZGJhY2sgaXMgdGhlIG9ubHkgdGhpbmcgdGhhdCBuZWVk cyB0byBiZSBkb25lIGJlZm9yZSBwcm9ncmVzc2luZyB0aGlzIGRyYWZ0IHRvIHRoZSBJRVNHIGZv ciBwdWJsaWNhdGlvbi48YnI+DQo8YnI+DQpUaW0sPGJyPg0KPGJyPg0KRGlkIFRlcm8ncyByZXNw b25zZSBhZGRyZXNzIHlvdXIgY29uY2VybnM/PGJyPg0KPGJyPg0KVGVybyw8YnI+DQo8YnI+DQpB cmUgeW91IG9yIHRoZSBvdGhlciBhdXRob3JzIHBsYW5uaW5nIHRvIHBvc3QgYW4gdXBkYXRlIGJh c2VkIG9uIHRoaXMgZmVlZGJhY2s/PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkRhdmU8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0OyAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogSVBzZWMgW21haWx0bzo8 YSBocmVmPSJtYWlsdG86aXBzZWMtYm91bmNlc0BpZXRmLm9yZyI+aXBzZWMtYm91bmNlc0BpZXRm Lm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBUZXJvIEtpdmluZW48YnI+DQomZ3Q7IFNlbnQ6IFRodXJz ZGF5LCBKYW51YXJ5IDEyLCAyMDE3IDg6MDMgQU08YnI+DQomZ3Q7IFRvOiBUaW1vdGh5IENhcmxp biAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRqY2FybGluQGlvbC51bmguZWR1Ij50amNhcmxpbkBpb2wu dW5oLmVkdTwvYT4mZ3Q7PGJyPg0KJmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOmlwc2VjQGlldGYu b3JnIj5pcHNlY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFtJUHNlY10gUmV2aWV3 IG9mIGRyYWZ0LWlldGYtaXBzZWNtZS1yZmM3MzIxYmlzLTAxPGJyPg0KJmd0Ozxicj4NCiZndDsg VGltb3RoeSBDYXJsaW4gd3JpdGVzOjxicj4NCiZndDsgJmd0OyBNeSBjb21tZW50czo8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgKiBTZWN0aW9uIDQgbWVudGlvbnMgdGhhdCB0aGF0IDI1 Ni1iaXQga2V5cyBhcmUgcmFpc2VkIHRvIHRoZSBTSE9VTEQ8YnI+DQomZ3Q7ICZndDsgbGV2ZWwu IFNob3VsZCB0aGlzIHJlYWQgYXMgdGhlc2UgYXJlIG5vdyB0aGUgTVVTVCBsZXZlbCBhczxicj4N CiZndDsgJmd0OyBFTkNSX0FFU19DQkMgYW5kPGJyPg0KJmd0OyAmZ3Q7IEVOQ1JfQUVTX0dDTV8x NiBhcmUgYXQgdGhlIE1VU1QgbGV2ZWwgYWNjb3JkaW5nIHRvIFRhYmxlIDEgKHdpdGggdGhlPGJy Pg0KJmd0OyAmZ3Q7IFsxXSBlbmRub3RlKT88YnI+DQomZ3Q7PGJyPg0KJmd0OyBZZXMsIEkgdGhp bmsgdGhpcyBpcyBpbmNvbnNpc3RhbmN5IGNhdXNlZCBieSBsYXN0IGVkaXRzLCBpLmUuLCB3aGVu IHdlIGNoYW5nZWQ8YnI+DQomZ3Q7IHRoZSAyNTYtYml0IGtleXMgdG8gTVVTVCwgd2Ugb25seSBl ZGl0ZWQgdGhlIGZvb3Rub3RlLCBhbmQgbWlzc2VkIHRoZSB0ZXh0PGJyPg0KJmd0OyBpbiBzZWN0 aW9uIDQuPGJyPg0KJmd0Ozxicj4NCiZndDsgU28gY29ycmVjdCBjaGFuZ2UgaXM6PGJyPg0KJmd0 Ozxicj4NCiZndDsgT0xEOjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0luIHRoYXQgc2Vuc2UgMjU2IGJpdCBr ZXlzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgc3RhdHVzIGhhcyBiZWVuIHJhaXNlZCBmcm9tIE1B WSBpbiBSRkM3MzIxIHRvIFNIT1VMRC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBORVc6PGJyPg0KJmd0 Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7SW4gdGhhdCBzZW5zZSAyNTYgYml0IGtleXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyBzdGF0dXMgaGFzIGJlZW4gcmFpc2VkIGZyb20gTUFZIGluIFJGQzczMjEgdG8gTVVTVC48YnI+ DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICogU2VjdGlvbiA1IG1lbnRpb25zIEVOQ1JfTlVMTF9BVVRI X0FFU19HTUFDLCB3aGljaCBpcyBub3Q8YnI+DQomZ3Q7IHJlZmVyZW5jZWQ8YnI+DQomZ3Q7ICZn dDsgYW55d2hlcmUgaW4gdGhlIGRvY3VtZW50LiZuYnNwOyBTaG91bGQgaXQgYmUgYWRkZWQgdG8g VGFibGUgMSBhdCB0aGUgTVVTVDxicj4NCiZndDsgJmd0OyBsZXZlbD88YnI+DQomZ3Q7PGJyPg0K Jmd0OyBOby4gSXQgaXMgTUFZIGxldmVsIGFsZ29yaXRobSwganVzdCBsaWtlIHRoZSBBVVRIX0FF U18xMjhfR01BQyBhbmQ8YnI+DQomZ3Q7IEFVVEhfQUVTXzI1Nl9HTUFDIGFsZ29yaXRobXMuIFRo ZSByZWFzb24gdGhvc2U8YnI+DQomZ3Q7IEFVVEhfQUVTX3sxMjgsMjU2fV9HTUFDIGFsZ29yaXRo bXMgYXJlIGxpc3RlZCBoZXJlIGlzLCB0aGF0IHRoZXkgdXNlZCB0bzxicj4NCiZndDsgYmUgU0hP VUxEJiM0MzssIGFuZCBhcmUgbm93IGRvd25ncmFkZWQgdG8gTUFZLjxicj4NCiZndDs8YnI+DQom Z3Q7IFRoZSBFTkNSX05VTExfQVVUSF9BRVNfR01BQyBoYXMgYmVlbiBNQVksIGFuZCB3aWxsIGJl IE1BWSwgc28gaXQgaXM8YnI+DQomZ3Q7IG5vdCBtZW50aW9uZWQgaW4gdGhlIHNlY3Rpb24gNC48 YnI+DQomZ3Q7PGJyPg0KJmd0OyBZb3VyIHRleHQgZWRpdHMgc2VlbWVkIHRvIGJlIGZpbmUuPGJy Pg0KJmd0OyAtLTxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmtpdmluZW5AaWtpLmZpIj5raXZp bmVuQGlraS5maTwvYT48YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCiZndDsgSVBzZWMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8 YSBocmVmPSJtYWlsdG86SVBzZWNAaWV0Zi5vcmciPklQc2VjQGlldGYub3JnPC9hPjxicj4NCiZn dDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBz ZWM8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpJUHNlYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SVBz ZWNAaWV0Zi5vcmciPklQc2VjQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_MWHPR09MB14404376A0CEC3627AA16A45F04B0MWHPR09MB1440namp_-- From nobody Mon Jan 30 17:26:50 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA0F12009C; Mon, 30 Jan 2017 17:26:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148582600877.29780.17755582008531715797.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2017 17:26:48 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc7321bis-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 01:26:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Authors : Daniel Migault John Mattsson Paul Wouters Yoav Nir Tero Kivinen Filename : draft-ietf-ipsecme-rfc7321bis-02.txt Pages : 13 Date : 2017-01-30 Abstract: This document updates the Cryptographic Algorithm Implementation Requirements for ESP and AH. The goal of these document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. This document obsoletes RFC 7321 on the cryptographic recommendations only. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc7321bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc7321bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc7321bis-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 Mon Jan 30 17:30: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 0797B12711D for ; Mon, 30 Jan 2017 17:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 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=-3.199] 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 qkNI4kGviP43 for ; Mon, 30 Jan 2017 17:30:12 -0800 (PST) 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 3B500127071 for ; Mon, 30 Jan 2017 17:30:12 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vC7wy0D4sz3HC for ; Tue, 31 Jan 2017 02:30:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1485826210; bh=gwNEPp4L9m/YHjCdzvFGh3ZrRmWXXbgyGzXJAajK1i8=; h=Date:From:To:Subject:In-Reply-To:References; b=JLs+X+VJoI1P0vyBRFWJH6aYrFHUe8Gd13Dm05DziKvWCbkWB9Hn1t2lorCOIqTKq 8ZrHBzGHhLkRZKrE2jz0EPycjxedVehADZC3YIuUboPbPrevAvcwWY4KXGui0T7VYn EDH9nW9Miwpfninzg0a2Z9mT4GzFkO/3XRrC952Y= 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 7NzQuIu58tU0 for ; Tue, 31 Jan 2017 02:30:08 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 31 Jan 2017 02:30:07 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0E9D03F284F; Mon, 30 Jan 2017 20:30:01 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 0E9D03F284F Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EE865445B28A for ; Mon, 30 Jan 2017 20:30:01 -0500 (EST) Date: Mon, 30 Jan 2017 20:30:01 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <148582600877.29780.17755582008531715797.idtracker@ietfa.amsl.com> Message-ID: References: <148582600877.29780.17755582008531715797.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc7321bis-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 01:30:14 -0000 On Mon, 30 Jan 2017, internet-drafts@ietf.org wrote: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc7321bis-02 The updated version addresses the issues raised by Timothy Carlin. Paul From nobody Tue Jan 31 10:21: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 F0CB51294FB for ; Tue, 31 Jan 2017 10:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FL4T7WQHkbs1 for ; Tue, 31 Jan 2017 10:21:09 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0093.outbound.protection.outlook.com [23.103.200.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8ED12948D for ; Tue, 31 Jan 2017 10:21:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PJlC6JYWNOa49nf4YrsMPqDSjkWeLXmu8iQ+OKTtC0Q=; b=Fq20YVszyliF7W5jP5d8NZGAv7Qh4gM+i9wrqsSUrdeUN6MqizlwKSmwlI9MpWrclOeq3gpAxmbJVwWVojtfcGvBlRB5H2cj1nhGofCTUaGhiC/9eSkiU2of3rl7bR1KlhRpn5lCQpoY5qhnL5wuC91esIVZRz0Gc5/urBswRKY= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1439.namprd09.prod.outlook.com (10.173.50.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Tue, 31 Jan 2017 18:21:07 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0874.020; Tue, 31 Jan 2017 18:21:07 +0000 From: "Waltermire, David A. (Fed)" To: "paul@nohats.ca" , "ipsec@ietf.org WG" Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-rfc7321bis-02.txt Thread-Index: AQHSe2EeIWe7yb6vtU2cmJvCB+DVH6FRzFKAgAEZzzA= Date: Tue, 31 Jan 2017 18:21:06 +0000 Message-ID: References: <148582600877.29780.17755582008531715797.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-ms-office365-filtering-correlation-id: 9cd70cab-ce5c-46e2-93d7-08d44a05ecb2 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR09MB1439; x-microsoft-exchange-diagnostics: 1; MWHPR09MB1439; 7:DuI7BdfNXdEbnXlbGJZR0r7pG6t2wg5HCR/TrhZ+3Fhfogq3I0xAxaxeeO4c4QnDmpdXXJdyC2q70JCAzVPGW9wjy3T4wS+agFuexx4h7UC+rghrALAqjqytFJ7qnu89ny4xKVcSxswWXcA3S/jZ5n7YKCd4rFnvk/4gmSUHIJW89d2mvyBXP3Wt5+3Zzyd6UutnN0X+/TfGt0wmufuuTFF2LAjQzu3hX+UVMmSy/Zwhq2k5hsisHoS93JCPB14WI0YeS5muFOpvZqdTMo9url/SFP/4y9lYH1zfYg6xveRPqj6APhOzOhD4PK7PEZLwpCnujyrGnGRdD70qQfilSp5FVIH/UgvlxMMXdV2yJbfq2jC0vzvHtSUdC4DZxnRBxH4CVpD3fr0kotIFkFCU6vxqph2f/wDzMBxVnw9suq2Hg+PUhg/86dei/0gzsbVL3cJRccCKmo2h+8YmhfPVStHjuYVpA547MFxY06E6EgmxPw1G6ouaPKUrQnChWTMXy/5qKOMHP/FunUoW/K2aDN1PhLXS7jaixQ0Gn+mFSHVAexN21Bv/UAzDG9Yqvbsd x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:MWHPR09MB1439; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1439; x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39410400002)(39850400002)(39840400002)(199003)(377454003)(189002)(13464003)(24454002)(74316002)(6116002)(7736002)(8676002)(50986999)(76176999)(3846002)(305945005)(81156014)(81166006)(54356999)(102836003)(101416001)(4326007)(8936002)(106356001)(105586002)(106116001)(122556002)(68736007)(86362001)(5001770100001)(2906002)(3280700002)(53936002)(97736004)(5660300001)(189998001)(229853002)(7696004)(2501003)(3660700001)(66066001)(6306002)(230783001)(9686003)(33656002)(2950100002)(99286003)(92566002)(55016002)(6436002)(38730400001)(2900100001)(77096006)(25786008)(6506006)(39060400001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1439; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2017 18:21:06.9718 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1439 Archived-At: Cc: Kathleen Moriarty Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc7321bis-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 18:21:11 -0000 Thank you Paul for making these edits and to the authors for their work on = the draft. I will be submitting this version to the IESG once the shepherd write up is= done. Thanks, Dave > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Wouters > Sent: Monday, January 30, 2017 8:30 PM > To: ipsec@ietf.org WG > Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc7321bis-02.txt >=20 > On Mon, 30 Jan 2017, internet-drafts@ietf.org wrote: >=20 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-rfc7321bis-02 >=20 > The updated version addresses the issues raised by Timothy Carlin. >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec