From nobody Mon Nov 3 17:44:16 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05451A1B55 for ; Mon, 3 Nov 2014 17:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hw0zF8oEdVOB for ; Mon, 3 Nov 2014 17:44:11 -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 8B4261A1B4F for ; Mon, 3 Nov 2014 17:44:11 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8EC6E20028; Mon, 3 Nov 2014 20:45:47 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 34573637F4; Mon, 3 Nov 2014 20:44:10 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 237C963740; Mon, 3 Nov 2014 20:44:10 -0500 (EST) From: Michael Richardson To: Kathleen Moriarty In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/eLyMJuqdS8dCf3Iujq26Tt2ouqg Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Charter review X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 01:44:13 -0000 --=-=-= Kathleen Moriarty wrote: > The chairs provided text for an updated charter in line with the newly > adopted working group items. The recharter text has been posted and > I'd like to give the WG a little time to comment prior to adding this > to a telechat for review. > Here is a link: > http://datatracker.ietf.org/doc/charter-ietf-ipsecme/ I agree with Paul Wouters that inclusion of channel binding into the charter is probably premature, and does not really jive with opportunistic security concepts that the application should not know/care that it is private, as there should be no extra authorization implied. Channel Binding is clearly easiest to implement if you can annotate individual TCP connections with their security properties, and this is probably easiest to do if you do kernel modifications. However, the draft-ietf-btns-abstract-api (which was never published) was designed specifically so that it did not require kernel changes, and proof of concept implementation back in 2005 (ish) did not require kernel changes. Still, I think that channel binding should be left off the charter for now: mostly because I don't think that we have the right people here to actually get the work done in a way that would result in a deployed standard. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVFgvZoCLcPvd0N1lAQKeGQf/Rlpw43s6QGMrXGnm1ODxosmT7nvqPW7A 1QTnKMs6AyMiFGpiiKdtRj1D9YHmEOpW+gKKXjNWMemUkdUdj8mYnYDhmXpdyiwf h470R71O3zac0gYKhWRiaKDeu900sag9WwGJli99sLvI1XDvHQ+PcVODKZMbYNAD sV9DryMXIH1NA3oFZqzd9DGKtzMbxdj8WxFgpCkOgK9RTKQC9gEDMP5xYbuO2Bm1 KP0ujthmobYznn/wiqAJ0N+nxWahfYnhMoXOZ+/AUD4Zhvib4pQRoSON/oHTD0R3 o2LkdorALjRDfrtBxSBJL2NknL9gs+b/O7U0RduHO8fv1DKLIz8qBQ== =ANAb -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 4 19:21:31 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A3C1A1BCC for ; Tue, 4 Nov 2014 19:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAtx_5RN52Ik for ; Tue, 4 Nov 2014 19:21:28 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CE81A1BB9 for ; Tue, 4 Nov 2014 19:21:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=961; q=dns/txt; s=iport; t=1415157689; x=1416367289; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=RfqbQm8fzELRCX6zci5Xr97voTI+bhmO/dGvN+ybXQM=; b=KJbkZIShqbJGBilTUg3cN3UW/146fLoYY9bnq1RhhPTEamCyAbAM1bLI 23TpH4VJ0MzB2vjBU6PVDw5I1kKqgnKR0APiwKDz2vyR3J46A/daNM5iW SwJekt2kpbvcxGRt6+mODRoY7o896XVRjZBVpNG8H0JGG8qX8vi6x2G81 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoLAHKXWVStJA2N/2dsb2JhbABYA4MOVFm7EwUBdJJaCodNAoEYFgEBAQEBfYQDAQEDAQEBATc0CwULC0YhBjAGE4gsAwkJDcBXDYYtAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4Y3iB+BWBEBHSMQBxGDHIEeBYt7ineFCoISgW6NdIZwhBceLwGBDoE8AQEB X-IronPort-AV: E=Sophos;i="5.07,317,1413244800"; d="scan'208";a="369669639" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP; 05 Nov 2014 03:21:27 +0000 Received: from sjc-vpn5-602.cisco.com (sjc-vpn5-602.cisco.com [10.21.90.90]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sA53LOhp020067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Nov 2014 03:21:26 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Weis In-Reply-To: Date: Tue, 4 Nov 2014 21:21:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6B331BE7-5972-48FC-9DFD-BA92222F938D@cisco.com> References: To: Kathleen Moriarty X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/PchiSUBZjoFvQOWV8hKGF3EpcjY Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Charter review X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 03:21:29 -0000 On Oct 31, 2014, at 4:05 PM, Kathleen Moriarty = wrote: > Hi, >=20 > The chairs provided text for an updated charter in line with the newly > adopted working group items. The recharter text has been posted and > I'd like to give the WG a little time to comment prior to adding this > to a telechat for review. I support the work item looking at defending against DDoS, and have no = objection to the opportunistic work item (after omitting the wording on = channel binding). Brian >=20 > Here is a link: >=20 > http://datatracker.ietf.org/doc/charter-ietf-ipsecme/ >=20 > Thanks. >=20 > --=20 >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --=20 Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From sulabh.off@gmail.com Tue Nov 4 20:52:50 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5481A87B3 for ; Tue, 4 Nov 2014 20:52:50 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPNCXG_yCae5 for ; Tue, 4 Nov 2014 20:52:48 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 633341A87B1 for ; Tue, 4 Nov 2014 20:52:48 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id tr6so9027153ieb.18 for ; Tue, 04 Nov 2014 20:52:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=R+iYnq4VEwHl3F/uauyp1sDcnUCIDx3qIIQ/SdmjjxQ=; b=ZM6xb95eBJ9cd+7v3YXjza1p1qED4F802/WjofNCZ6WaK4m38OH5+UTvkZJoYgt/uj 22itvQ9RGSFgpOV0E/leyKpH7T8q09W52ZhAHjqYLl0T/mEN9iARHh7o1gKxjCeGnHbv LB+60rmNBLGnrZ5UcTlUAn3rQVtITjmLSvj5PxIGBYvqlFMUjZylXr1kc94czMFePqLj K7wMLTdKq9HBNKTseY5r6ldD7kEaFn+RHfN0Aos9nmy3+c9AaXc1TA9sNLp+ljHkxQ93 d70zWV7ZzA6nAd88fcnlwWeqzM182DmY/ihihp88wtU8EPvmZLYfSDSCpsLjCPXnyKGQ v8Uw== MIME-Version: 1.0 X-Received: by 10.43.143.18 with SMTP id jk18mr2062768icc.73.1415163167521; Tue, 04 Nov 2014 20:52:47 -0800 (PST) Received: by 10.107.165.202 with HTTP; Tue, 4 Nov 2014 20:52:47 -0800 (PST) Date: Tue, 4 Nov 2014 22:52:47 -0600 Message-ID: From: sulabh jain To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=001a11c2af94e6859e0507155943 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/BwQdKUCYP47J-BKQiDlglA-Y-yw Subject: [IPsec] sending a certificate without receiving certificate request from sender X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 05:35:56 -0000 --001a11c2af94e6859e0507155943 Content-Type: text/plain; charset=ISO-8859-1 Hi Ipsec experts, RFC 5996 section 3.7 3.7 . Certificate Request Payload The Certificate Request payload, denoted CERTREQ in this document, provides a means to request preferred certificates via IKE and can appear in the IKE_INIT_SA response and/or the IKE_AUTH request. Certificate Request payloads* MAY* be included in an exchange when the sender needs to get the certificate of the receiver. Does that leave a scope for the following use case: The sender does not send a cert request payload, but still expects a certificate in the Auth Response. Regards Sulabh --001a11c2af94e6859e0507155943 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ipsec experts,
=A0
RFC 5996 section 3.7

3.7.=A0 Cer= tificate Request Payload


=A0=A0 The Certificate Request payload, denoted CERTREQ in thi= s document,
=A0=A0 provides a means to request preferred certificates vi= a IKE and can
=A0=A0 appear in the IKE_INIT_SA response and/or the IKE_A= UTH request.
=A0=A0 Certificate Request payloads MAY be= included in an exchange when the
=A0=A0 sender needs to get the certifi= cate of the receiver.
=A0
Does that leave a scope for the following use case:
=A0
The sender does not send a cert request payload, but still expects a c= ertificate in the Auth Response.

=A0
Regards
Sulabh
--001a11c2af94e6859e0507155943-- From nobody Wed Nov 5 00:18:31 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5761A87EB for ; Wed, 5 Nov 2014 00:18:30 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXpLG34Dazw0 for ; Wed, 5 Nov 2014 00:18:28 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA611A87EA for ; Wed, 5 Nov 2014 00:18:28 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id a1so271940wgh.20 for ; Wed, 05 Nov 2014 00:18:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=EL96hRwFlWEKstfSOH+0q7Panc2A3TGPKYU19AAxbSo=; b=aRwJIRhFtu0fwNrx20UIv4KVt9k/iI3+PB0T3kDclrDB+TeQJsbS2DEvMVIhvDmp1M kl4j8SOjflu3tVrQkN80W0SenXJZlKebQd6DpOXIeaQV+UIhaUuwBTNcg+ygDiffeV3t YR/oeBK1Kw8dd6dvACFQHE8AGD1hdAkrAjV9eBKLyVMee45XKpqgw40x4i4uDrEiTiKi 9T9RVL/xxZ5QAw1hqZM1tEnL8WUDDutn2bx8r+eX1BhyB0nVUbcMhV4RkkPKtrK2ebRT DELAyRxxrgEzgIDfIIppW0rsY80hajuXzcWx6xn/OYrESj1hdHuzn2CNwtTS7oRYY5je rlhw== X-Received: by 10.194.2.244 with SMTP id 20mr24606453wjx.4.1415175506872; Wed, 05 Nov 2014 00:18:26 -0800 (PST) Received: from [172.24.250.114] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id wx3sm3181853wjc.19.2014.11.05.00.18.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Nov 2014 00:18:26 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_49220BF9-C155-4D04-B770-87F25E74E7CE" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: Date: Wed, 5 Nov 2014 10:18:25 +0200 Message-Id: <34676991-846F-47E9-85ED-6A190A9CC260@gmail.com> References: To: sulabh jain X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/CUJNdmTO80YrGdteckv-LPFqKs0 Cc: ipsec@ietf.org Subject: Re: [IPsec] sending a certificate without receiving certificate request from sender X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 08:18:30 -0000 --Apple-Mail=_49220BF9-C155-4D04-B770-87F25E74E7CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 It=92s possible, but then why not send it? The intent is not to prevent communication through the strict adherence of selection of a certificate based on CERTREQ, when an alternate certificate could be selected by the sender that would still enable the recipient to successfully validate and trust it through trust conveyed by cross-certification, CRLs, or other out-of-band configured means. Thus, the processing of a CERTREQ should be seen as a suggestion for a certificate to select, not a mandated one. If no certificates exist, then the CERTREQ is ignored. This is not an error condition of the protocol. There may be cases where there is a preferred CA sent in the CERTREQ, but an alternate might be acceptable (perhaps after prompting a human operator). > On Nov 5, 2014, at 6:52 AM, sulabh jain wrote: >=20 > Hi Ipsec experts, > =20 > RFC 5996 section 3.7 > 3.7 . Certificate = Request Payload >=20 >=20 >=20 > The Certificate Request payload, denoted CERTREQ in this document, > provides a means to request preferred certificates via IKE and can > appear in the IKE_INIT_SA response and/or the IKE_AUTH request. > Certificate Request payloads MAY be included in an exchange when = the > sender needs to get the certificate of the receiver. > =20 > Does that leave a scope for the following use case: > =20 > The sender does not send a cert request payload, but still expects a = certificate in the Auth Response. >=20 > =20 > Regards > Sulabh > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_49220BF9-C155-4D04-B770-87F25E74E7CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 It=92s possible, but then why not send it?
   The intent is not to =
prevent communication through the strict
   adherence of selection of a certificate based on CERTREQ, when an
   alternate certificate could be selected by the sender that would
   still enable the recipient to successfully validate and trust it
   through trust conveyed by cross-certification, CRLs, or other
   out-of-band configured means.  Thus, the processing of a CERTREQ
   should be seen as a suggestion for a certificate to select, not a
   mandated one.  If no certificates exist, then the CERTREQ is ignored.
   This is not an error condition of the protocol.  There may be cases
   where there is a preferred CA sent in the CERTREQ, but an alternate
   might be acceptable (perhaps after prompting a human operator).

On Nov 5, 2014, at 6:52 AM, sulabh jain = <sulabh.off@gmail.com> wrote:

Hi = Ipsec experts,
 
RFC 5996 section 3.7

3.7.  Certificate = Request Payload


   The = Certificate Request payload, denoted CERTREQ in this document,
   provides a means to request preferred = certificates via IKE and can
   appear in the = IKE_INIT_SA response and/or the IKE_AUTH request.
   Certificate Request payloads = MAY be included in an exchange when the
   sender needs to get the certificate of the = receiver.
 
Does that leave a scope for the following use = case:
 
The sender does not send a cert request payload, but = still expects a certificate in the Auth Response.

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

= --Apple-Mail=_49220BF9-C155-4D04-B770-87F25E74E7CE-- From nobody Wed Nov 5 06:28:38 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A5A1A1B46 for ; Wed, 5 Nov 2014 06:28:37 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DW0Lo2cBHCL for ; Wed, 5 Nov 2014 06:28:34 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3470B1A891C for ; Wed, 5 Nov 2014 06:28:34 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id x19so778498ier.2 for ; Wed, 05 Nov 2014 06:28:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sqYxlA7x+nfP5WNz796Uce869drzvDKSyrCSKJ3xWHA=; b=EPZFPJfe3f6C479KIAHCBN878cA0iO9DMjt7V3OnViSWmoaQwoOUk90t89RsSji/mQ cAlFFKDSF+uLpS+U6qMSUrv7i6Oio9QVlmcQBYm9gg4D0itbZz8xdSMjff2nGOaGrUgg 8EwFiJFBV0daKOr0nIra2NQieTTdBJeYVRvYTVQP7iiNMTjGyEVboLaatkkS7aWCNsbA YQKDenQG66Gzp3t2xhuNv5YxWUP+hUn71jYdBxit9ZVfmkB7f+Tbo7MS8vFzXJj+c0+L x1A+FFNN3JXx/Th5cMhA9CYzLQL+iNZViuErYye22qYAXAiZYEOtJZXevM/qu/n1GxPM jG6g== MIME-Version: 1.0 X-Received: by 10.43.128.71 with SMTP id hd7mr4813240icc.36.1415197713419; Wed, 05 Nov 2014 06:28:33 -0800 (PST) Received: by 10.107.165.202 with HTTP; Wed, 5 Nov 2014 06:28:33 -0800 (PST) In-Reply-To: References: <34676991-846F-47E9-85ED-6A190A9CC260@gmail.com> Date: Wed, 5 Nov 2014 08:28:33 -0600 Message-ID: From: sulabh jain To: Yoav Nir Content-Type: multipart/alternative; boundary=001a11c20560fed3cf05071d64cc Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/DUFcUo21JDt8bucqCOoMp-rHARE Cc: ipsec@ietf.org Subject: Re: [IPsec] sending a certificate without receiving certificate request from sender X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 14:28:37 -0000 --001a11c20560fed3cf05071d64cc Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 5, 2014 at 8:26 AM, sulabh jain wrote: > The text below only says that the CERTREQ is a suggestion for a preffered > Certificate, which as well may be ignored and a different Certificate can > be presented in response. But it does not say that without receiving the > CERTREQ, a certificate should be sent back. > > RFC 4945 > > 3.2.6. Presence or Absence of Certificate Request Payloads > > When in-band exchange of certificate keying materials is desired, > implementations MUST inform the peer of this by sending at least one > CERTREQ. In other words, an implementation that does not send any > CERTREQs during an exchange SHOULD NOT expect to receive any CERT > payloads. > > Now, looking at this one would say an implementation will be non compliant > if it did not send a CERTREQ and expected a certificate in response. > > > Also the same RFC says: > > 3.3.6. Certificate Payloads Not Mandatory > An implementation that does not receive any CERTREQs during an > exchange SHOULD NOT send any CERT payloads, except when explicitly > configured to proactively send CERT payloads in order to interoperate > with *non-compliant* implementations that fail to send CERTREQs even > when certificates are desired. > > Now my question will be, an implementation that is not sending a CERTREQ > and expecting a certificate, will that be non compiant to the standards ? > As per above ? > > Regards > Sulabh > On Wed, Nov 5, 2014 at 2:18 AM, Yoav Nir wrote: > >> It's possible, but then why not send it? >> >> The intent is not to prevent communication through the strict >> adherence of selection of a certificate based on CERTREQ, when an >> alternate certificate could be selected by the sender that would >> still enable the recipient to successfully validate and trust it >> through trust conveyed by cross-certification, CRLs, or other >> out-of-band configured means. Thus, the processing of a CERTREQ >> should be seen as a suggestion for a certificate to select, not a >> mandated one. If no certificates exist, then the CERTREQ is ignored. >> This is not an error condition of the protocol. There may be cases >> where there is a preferred CA sent in the CERTREQ, but an alternate >> might be acceptable (perhaps after prompting a human operator). >> >> >> On Nov 5, 2014, at 6:52 AM, sulabh jain wrote: >> >> Hi Ipsec experts, >> >> RFC 5996 section 3.7 >> 3.7 . Certificate >> Request Payload >> >> >> The Certificate Request payload, denoted CERTREQ in this document, >> provides a means to request preferred certificates via IKE and can >> appear in the IKE_INIT_SA response and/or the IKE_AUTH request. >> Certificate Request payloads* MAY* be included in an exchange when the >> sender needs to get the certificate of the receiver. >> >> Does that leave a scope for the following use case: >> >> The sender does not send a cert request payload, but still expects a >> certificate in the Auth Response. >> >> >> Regards >> Sulabh >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> > --001a11c20560fed3cf05071d64cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 5, 2014 at 8:26 AM, sulabh jain <sulabh.off@gmail.com> wrote:
The text below only says that the CERTREQ is a suggestion for a preffe= red Certificate, which as well may be ignored and a different Certificate c= an be presented in response. But it does not say that without receivin= g the CERTREQ, a certificate should be sent back.
 
RFC 4945
 
3.2.6.  Presence or Absence of Certificate Request Payloads
   When in-band exchange of certificate keying materials is des= ired,
   implementations MUST inform the peer of this by sendi= ng at least one
   CERTREQ.  In other words, an implement= ation that does not send any
   CERTREQs during an exchange SH= OULD NOT expect to receive any CERT
   payloads.
 
Now, looking at this one would say an implementation will be non compl= iant if it did not send a CERTREQ and expected a certificate in response.
 
 
Also the same RFC says:
 
3.3.6.  Certificate Payloads Not Mandatory
An implementation t= hat does not receive any CERTREQs during an
   exchange SHOULD= NOT send any CERT payloads, except when explicitly
   configu= red to proactively send CERT payloads in order to interoperate
 &nb= sp; with non-compliant implementations that fail to send C= ERTREQs even
   when certificates are desired.
 
Now my question will be, an implementation that is not sending a CERTR= EQ and expecting a certificate, will that be non compiant to the standards = ? As per above ?
 
Regards
Sulabh
On Wed, Nov 5, 2014 at 2:18 AM, Yoav Nir <yni= r.ietf@gmail.com> wrote:
It’s possible, but then why not s= end it?=20 
   The i=
ntent is not to prevent communication through the strict
   adherence of selection of a certificate based on CERTREQ, when an
   alternate certificate could be selected by the sender that would
   still enable the recipient to successfully validate and trust it
   through trust conveyed by cross-certification, CRLs, or other
   out-of-band configured means.  Thus, the processing of a CERTREQ
   should be seen as a suggestion for a certificate to select, not a
   mandated one.  If no certificates exist, then the CERTREQ is ignored.
   This is not an error condition of the protocol.  There may be cases
   where there is a preferred CA sent in the CERTREQ, but an alternate
   might be acceptable (perhaps after prompting a human operator).

On Nov 5, 2014, at 6:52 AM, sulabh jain <sulabh.off@gmail.com> wrote:
Hi Ipsec experts,
 
RFC 5996 section 3.7

3.7.  Certificate Request Payload


   The Certificate Request payload, denoted CERTREQ = in this document,
   provides a means to request preferred cer= tificates via IKE and can
   appear in the IKE_INIT_SA respons= e and/or the IKE_AUTH request.
   Certificate Request payloads= MAY be included in an exchange when the
   s= ender needs to get the certificate of the receiver.
 
Does that leave a scope for the following use case:
 
The sender does not send a cert request payload, but still expects a c= ertificate in the Auth Response.

 
Regards
Sulabh
______________________________________________= _
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



--001a11c20560fed3cf05071d64cc-- From nobody Thu Nov 6 15:36:07 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFE11A00F6 for ; Thu, 6 Nov 2014 15:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxEdPZ_Brrpi for ; Thu, 6 Nov 2014 15:36:01 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A63A91A00BF for ; Thu, 6 Nov 2014 15:36:01 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 195FA10224008; Thu, 6 Nov 2014 15:36:01 -0800 (PST) Received: from 50.84.73.21 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 6 Nov 2014 15:36:01 -0800 (PST) Message-ID: <9bb29bdb72d4710b6960d898420152b8.squirrel@www.trepanning.net> In-Reply-To: <6B331BE7-5972-48FC-9DFD-BA92222F938D@cisco.com> References: <6B331BE7-5972-48FC-9DFD-BA92222F938D@cisco.com> Date: Thu, 6 Nov 2014 15:36:01 -0800 (PST) From: "Dan Harkins" To: "Brian Weis" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/pAxTI4ft4DaOt4owRTMxdzxuo7A Cc: "ipsec@ietf.org" , Kathleen Moriarty Subject: Re: [IPsec] Charter review X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 23:36:05 -0000 On Tue, November 4, 2014 7:21 pm, Brian Weis wrote: > On Oct 31, 2014, at 4:05 PM, Kathleen Moriarty > wrote: > >> Hi, >> >> The chairs provided text for an updated charter in line with the newly >> adopted working group items. The recharter text has been posted and >> I'd like to give the WG a little time to comment prior to adding this >> to a telechat for review. > > I support the work item looking at defending against DDoS, and have no > objection to the opportunistic work item (after omitting the wording on > channel binding). +1 How about we also get rid of the mention of a formal security proof of opportunistic encryption? The security is just that afforded by D-H. Dan. > Brian > >> >> Here is a link: >> >> http://datatracker.ietf.org/doc/charter-ietf-ipsecme/ >> >> Thanks. >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > -- > Brian Weis > Security, Enterprise Networking Group, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Thu Nov 6 17:32:16 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2B51ACE5D; Thu, 6 Nov 2014 17:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.496 X-Spam-Level: X-Spam-Status: No, score=-107.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hfLlPRCyJRl; Thu, 6 Nov 2014 17:31:59 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 285C01ACE4D; Thu, 6 Nov 2014 17:31:58 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id DDD2E181C99; Thu, 6 Nov 2014 17:31:43 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20141107013143.DDD2E181C99@rfc-editor.org> Date: Thu, 6 Nov 2014 17:31:43 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/df4eGnf9JwD6u_sRB484mkr3vgc Cc: ipsec@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org Subject: [IPsec] RFC 7383 on Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 01:32:05 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7383 Title: Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation Author: V. Smyslov Status: Standards Track Stream: IETF Date: November 2014 Mailbox: svan@elvis.ru Pages: 20 Characters: 47354 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsecme-ikev2-fragmentation-10.txt URL: https://www.rfc-editor.org/rfc/rfc7383.txt This document describes a way to avoid IP fragmentation of large Internet Key Exchange Protocol version 2 (IKEv2) messages. This allows IKEv2 messages to traverse network devices that do not allow IP fragments to pass through. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Nov 6 18:03:16 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A391ACE73 for ; Thu, 6 Nov 2014 18:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzdbQk4i6f_o for ; Thu, 6 Nov 2014 18:03:12 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 095B61ACE70 for ; Thu, 6 Nov 2014 18:03:12 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 24AAD80056; Thu, 6 Nov 2014 21:03:09 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1415325789; bh=PwmZDS7L7aldvFz4cM+mv3E9ITzRSocP626MCbdjpwk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=RczECelI/EDUwaUXZMOuCNjvWLxVHg+9Lmx7GL63U8aectkzdW6URGF5dm6xS1d96 Rvp/miDAV9KPc46dEcyvbMaNnODHC06sNUCDgio44y9xDhVxjBH3XgX1wbs07R0HC/ txYYwijQVNimCuPT/MmYAb6tQwejMNjEBeJna720= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sA7237SW007351; Thu, 6 Nov 2014 21:03:08 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 6 Nov 2014 21:03:07 -0500 (EST) From: Paul Wouters To: Dan Harkins In-Reply-To: <9bb29bdb72d4710b6960d898420152b8.squirrel@www.trepanning.net> Message-ID: References: <6B331BE7-5972-48FC-9DFD-BA92222F938D@cisco.com> <9bb29bdb72d4710b6960d898420152b8.squirrel@www.trepanning.net> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/3ezz_HAGxH8DU8kkPJkVI5jLz04 Cc: "ipsec@ietf.org" , Kathleen Moriarty , Brian Weis Subject: Re: [IPsec] Charter review X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 02:03:15 -0000 On Thu, 6 Nov 2014, Dan Harkins wrote: >> I support the work item looking at defending against DDoS, and have no >> objection to the opportunistic work item (after omitting the wording on >> channel binding). > > +1 > > How about we also get rid of the mention of a formal security proof > of opportunistic encryption? The security is just that afforded by D-H. Maybe replace it with wording to ensure opportunistic will not reduce the security of the non-opportunstic parts that might be added. I think that was the mean concern. Paul From nobody Fri Nov 7 00:03:36 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7047F1ACF17 for ; Fri, 7 Nov 2014 00:03:31 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EebF2Aa3Zxe1 for ; Fri, 7 Nov 2014 00:03:27 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F32DC1ACF0B for ; Fri, 7 Nov 2014 00:03:26 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hi2so3743277wib.7 for ; Fri, 07 Nov 2014 00:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Q8dtZFPeZjXpvd/vInA/In2itYmy+iIKtpU3ibNIB+M=; b=dNB9LFMM24T0ojGd45m1PmdaorgdUBCD6Vnc76FIp3fw3c9QX8vNEDKuPiTWmdsCCO taYs0hlSf2tw/bkYnojqU+48BGOOWqh+siUeJP+9so0coP5q6eO5UU5PVMQruLG3kgY1 lJyrAC8hMr7Vpb/tHWgwuXLQtcVu+Haz0KvChWTsCW3oPWRWuXSUF53mTjd3a2aTfhAZ b71p+rpXXatmcJzJRG20pDWLQqwXwNh+C2j5bSSFzJcXvEU/o5lhOnyb377ifddSskJE DAzsWB5dRZRPl8BkXha42U5aQIWe+aQ2YX/kVfqGcVWmm5NJUUorU+Rx3kZ+llxh5B95 g1fw== X-Received: by 10.194.185.229 with SMTP id ff5mr12770683wjc.122.1415347405599; Fri, 07 Nov 2014 00:03:25 -0800 (PST) Received: from [10.0.0.9] (bzq-79-177-61-89.red.bezeqint.net. [79.177.61.89]) by mx.google.com with ESMTPSA id lm9sm10740421wjc.45.2014.11.07.00.03.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Nov 2014 00:03:25 -0800 (PST) Message-ID: <545C7CCC.9030402@gmail.com> Date: Fri, 07 Nov 2014 10:03:24 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Dan Harkins , Brian Weis References: <6B331BE7-5972-48FC-9DFD-BA92222F938D@cisco.com> <9bb29bdb72d4710b6960d898420152b8.squirrel@www.trepanning.net> In-Reply-To: <9bb29bdb72d4710b6960d898420152b8.squirrel@www.trepanning.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/a3_iOp6lvEoyuTwq-wzc7THM1ug Cc: "ipsec@ietf.org" , Kathleen Moriarty Subject: Re: [IPsec] Charter review X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 08:03:34 -0000 Regarding formal security proofs, I strongly disagree. The current wording is extremely mild. It does not require an actual security proof (which would not be realistic), but says "The solution should be in line with current best practices, including ... possible formal protocol security proofs." This to me means that people have looked at the modified protocol and can say that the new stuff does not inhibit such a security proof in the future, and that we formally understand the security properties that are supposed to be provided by the protocol. We are making a major change to IKE, and as much as I care about its goals, we should try to do it right. Relying on "the security afforded by DH" is not easy when in the real world, both peers might be reusing exponents and/or using too short DH groups. Thanks, Yaron On 11/07/2014 01:36 AM, Dan Harkins wrote: > > On Tue, November 4, 2014 7:21 pm, Brian Weis wrote: >> On Oct 31, 2014, at 4:05 PM, Kathleen Moriarty >> wrote: >> >>> Hi, >>> >>> The chairs provided text for an updated charter in line with the newly >>> adopted working group items. The recharter text has been posted and >>> I'd like to give the WG a little time to comment prior to adding this >>> to a telechat for review. >> >> I support the work item looking at defending against DDoS, and have no >> objection to the opportunistic work item (after omitting the wording on >> channel binding). > > +1 > > How about we also get rid of the mention of a formal security proof > of opportunistic encryption? The security is just that afforded by D-H. > > Dan. > >> Brian >> >>> >>> Here is a link: >>> >>> http://datatracker.ietf.org/doc/charter-ietf-ipsecme/ >>> >>> Thanks. >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >> >> -- >> Brian Weis >> Security, Enterprise Networking Group, Cisco Systems >> Telephone: +1 408 526 4796 >> Email: bew@cisco.com >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Fri Nov 7 06:08:23 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9774C1AD021 for ; Fri, 7 Nov 2014 06:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzuMYVPb38Af for ; Fri, 7 Nov 2014 06:08:20 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF1E1AD01C for ; Fri, 7 Nov 2014 06:08:20 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id A5D2810224008; Fri, 7 Nov 2014 06:08:19 -0800 (PST) Received: from 66.140.241.100 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 7 Nov 2014 06:08:19 -0800 (PST) Message-ID: In-Reply-To: <545C7CCC.9030402@gmail.com> References: <6B331BE7-5972-48FC-9DFD-BA92222F938D@cisco.com> <9bb29bdb72d4710b6960d898420152b8.squirrel@www.trepanning.net> <545C7CCC.9030402@gmail.com> Date: Fri, 7 Nov 2014 06:08:19 -0800 (PST) From: "Dan Harkins" To: "Yaron Sheffer" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/AFq7EpssNR96LpnBJtxrMscQG_c Cc: "ipsec@ietf.org" , Kathleen Moriarty , Brian Weis , Dan Harkins Subject: Re: [IPsec] Charter review X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 14:08:22 -0000 On Fri, November 7, 2014 12:03 am, Yaron Sheffer wrote: > > > Regarding formal security proofs, I strongly disagree. > > The current wording is extremely mild. It does not require an actual > security proof (which would not be realistic), but says "The solution > should be in line with current best practices, including ... possible > formal protocol security proofs." > > This to me means that people have looked at the modified protocol and > can say that the new stuff does not inhibit such a security proof in the > future, and that we formally understand the security properties that are > supposed to be provided by the protocol. > > We are making a major change to IKE, and as much as I care about its > goals, we should try to do it right. Relying on "the security afforded > by DH" is not easy when in the real world, both peers might be reusing > exponents and/or using too short DH groups. This "major change" is to remove authentication. Peers reusing exponents is already entirely permissible in IKE. Authenticating a reused exponent does not change the problem caused by reusing an exponent. I don't even know what "too short DH groups" are but if you can do it in IKE with authentication then what's the issue that is introduced when you take away authentication? I welcome the new interest in formal security proofs in the IETF but I don't think this particular charter change compels one. regards, Dan. From nobody Tue Nov 11 16:03:30 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFDE1A8709 for ; Tue, 11 Nov 2014 16:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fw4SuWIFFmw for ; Tue, 11 Nov 2014 16:03:25 -0800 (PST) Received: from avasout01.plus.net (avasout01.plus.net [84.93.230.227]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D9021A70E2 for ; Tue, 11 Nov 2014 16:03:24 -0800 (PST) Received: from [192.168.1.2] ([80.229.245.222]) by avasout01 with smtp id EQ3J1p0034odrNw01Q3KSK; Wed, 12 Nov 2014 00:03:23 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=IfMJWAaa c=1 sm=1 tr=0 a=ZDAw9H2lLuf1cmfnewsGHg==:117 a=ZDAw9H2lLuf1cmfnewsGHg==:17 a=0Bzu9jTXAAAA:8 a=rkJuIV0pGx0A:10 a=N659UExz7-8A:10 a=apiPipScAAAA:8 a=XFt7pEl5zbGBE4Fr1RYA:9 a=WfTz583jRwJVuY2s:21 a=QskQkIOqPBXeExGu:21 a=pILNOxqGKmIA:10 X-AUTH: putwet+t-ietf:2500 Message-ID: <5462A3C5.8050601@putwet.me.uk> Date: Wed, 12 Nov 2014 00:03:17 +0000 From: Tony Putman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Rodney Van Meter References: <14BE57EA00BC0C469E17B5AD698FE67783D07A82@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <14BE57EA00BC0C469E17B5AD698FE67783D07A82@FR711WXCHMBA03.zeu.alcatel-lucent.com> X-Forwarded-Message-Id: <14BE57EA00BC0C469E17B5AD698FE67783D07A82@FR711WXCHMBA03.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/O_Sb5H9WfcXGuMD3xB_JZJBXces Cc: ipsec , Shota Nagayama , Shigeya Suzuki Subject: Re: [IPsec] IPsec with QKD X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 00:03:27 -0000 Rod, I read your draft with interest and have a number of comments and questions. I've not been around long enough to remember previous discussions on this (and couldn't find anything after a cursory search in archives), so please forgive me if I'm rehashing previous arguments. The QKD keys (and other similar out-of-band keys) are associated with key agreement, so it makes sense to me to reuse the KE payload. This would allow standard notifications and negotiations to take place. It also means that you don't need to define a new payload and tranform, only get IDs assigned to cover OOB key sharing; the way the key information is packed into the structure also needs to be defined. Possibly the above was suggested previously and rejected. If so, I would suggest producing a new payload which has exactly the same structure and behaviour as the KE payload. In other words: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Exchange Method Num | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QKD Device ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Key ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It's not clear to me how the actual key is used. Your draft says that the KE and Nonce payloads are not needed, so I assume that you propose that the key be used directly as SKEYSEED. I suggest instead that the Nonces are retained, and that the key simply replaces the g^ir factor; that is (for the IKE SA): SKEYSEED = prf(Ni | Nr, QKD key) You have said that keys MUST NOT be reused. This seems overly restrictive to me, and opens you to denial of service attacks. An attacker would be able to very quickly exhaust your keys if each IKE_SA_INIT exchange used up a key, whether or not the subsequent authentication phase succeeded. Provided you make use of the nonces as I suggest above, you could allow reuse of keys which were part of a failed exchange (up to a limit): the encrypted part of the subsequent IKE_AUTH message would use different keys each time. Since we are in any case making assumptions about the security of the IPsec ciphers, this seems to leak very little information about the QKD key. I don't understand the fallback concept. I would have thought that this could be negotiated at the time that rekeying (or creating a new Child SA) was needed. In other words, the end which initiates the rekey can use a QKD KE payload, and may include SAs with a DH transform (equivalent to Diffie-Hellman fallback) or no KE transform (equivalent to Continue fallback). If the initiator is simply making a suggestion that a fallback transform would be acceptable, so as to save QKD keys, then I suggest using a Notify payload instead of defining a new one. In section 3.1.3, you define a new transform type. As I say above, this is not needed if there is general acceptance to define a new KE Transform Id for QKD; if there is not, then I agree this is necessary. However, you should not define the new Transform Id(s) here: that should also be left to IANA. It is not clear to me how PAK-DH provides any meaningful additional security, but if you wish to include it in this document then you need to define clearly how it applies to IKEv2: RFC5683 is very general and more specific information will be needed here. Lastly, something which seems to be missing is a discussion and specification of QKD key size. Is this assumed to be implicit in the Key ID? It seems to me that this would be a parameter which needs negotiation. As such, I would expect to see multiple Transform IDs for QKD, each representing a different key size. It may be possible to do this using an attribute instead, but I think that this would complicate negotiation (e.g. the INVALID_KE_PAYLOAD indicates which transform it prefers, and this doesn't have space for an attribute). Regards, Tony From nobody Tue Nov 11 19:22:42 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124671AC3EA for ; Tue, 11 Nov 2014 19:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.791 X-Spam-Level: X-Spam-Status: No, score=-97.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=0.6, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kwy6GDP3WRYx for ; Tue, 11 Nov 2014 19:22:36 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66881AC3EB for ; Tue, 11 Nov 2014 19:22:35 -0800 (PST) Received: from dhcp-a0a0.meeting.ietf.org (dhcp-a0a0.meeting.ietf.org [31.133.160.160]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C253727812F; Wed, 12 Nov 2014 12:22:31 +0900 (JST) Content-Type: multipart/alternative; boundary="Apple-Mail=_9C8E43C3-8E27-492F-9C08-0109C6D4A52E" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Rodney Van Meter In-Reply-To: <5462A3C5.8050601@putwet.me.uk> Date: Tue, 11 Nov 2014 22:22:28 -0500 Message-Id: <34767662-9F6F-4C36-8B77-1787FD705157@sfc.wide.ad.jp> References: <14BE57EA00BC0C469E17B5AD698FE67783D07A82@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5462A3C5.8050601@putwet.me.uk> To: Tony Putman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/bNOulcECva-Q70M_Wxl1oXt_mYA Cc: Rodney Van Meter , ipsec , Shota Nagayama , Shigeya Suzuki Subject: Re: [IPsec] IPsec with QKD X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 03:22:40 -0000 --Apple-Mail=_9C8E43C3-8E27-492F-9C08-0109C6D4A52E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks Tony, good thoughts. Let me try to respond, though a couple of = these are really Shota=92s expertise, so if I misrepresent something = hopefully he=92ll correct me. (Man, it took me much of the afternoon to read through this, dig through = a little code and some RFCs, and I still haven=92t completely answered = all your questions, but it=92s luau time=85) On Nov 11, 2014, at 7:03 PM, Tony Putman wrote: >=20 > Rod, >=20 > I read your draft with interest and have a number of comments and > questions. I've not been around long enough to remember previous > discussions on this (and couldn't find anything after a cursory search > in archives), so please forgive me if I'm rehashing previous = arguments. Most of the prior discussion was in person or in private email; little = to nothing happened on the ML during the discussion of the -00 draft. = (A couple of the experts who reviewed it are probably not even on the = ML.) This time around, we have input from you, Paul Koning, Greg Troxler (who = implemented the first version of this), and offline, Tero and a couple = of senior people. Does this mean that there is enough interest from the WG that this = should be a work item? Would be happy to have that as an outcome. >=20 > The QKD keys (and other similar out-of-band keys) are associated with > key agreement, so it makes sense to me to reuse the KE payload. This > would allow standard notifications and negotiations to take place. It > also means that you don't need to define a new payload and tranform, > only get IDs assigned to cover OOB key sharing; the way the key > information is packed into the structure also needs to be defined. The KE Payload explicitly names fields like Diffie-Hellman Group Num. = It=92s pretty closely tied to D-H. RFC 5996 says, "The Key Exchange = payload, denoted KE in this document, is used to exchange Diffie-Hellman = public numbers as part of a Diffie-Hellman key exchange.=94 I=92m = opposed to shoehorning something with rather different semantics into = the same stuff, and adding caveats like, =93We know that the normal use = is for D-H group number, but we cheat and use it instead to mean=85=94 = That approach seems likely to lead to maintainability problems down the = road, including on things like having non-D-H items listed in the table = of group numbers. >=20 > Possibly the above was suggested previously and rejected. If so, I > would suggest producing a new payload which has exactly the same > structure and behaviour as the KE payload. In other words: >=20 > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Payload |C| RESERVED | Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Key Exchange Method Num | RESERVED | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | QKD Device ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Key ID ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ So in this case, your figure above reuses the KE Payload ID, or not? I = think you=92re asking for a new Payload ID here (same as we are), just = want to be clear. I=92m not opposed to the new QKD (or OOB) Payload hewing fairly closely = to the format of KE, but we did add some fields in our QKD ID Payload. = For the record, here=92s the current format, from the I-D: QKD KeyID Payload 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! version !F! flags ! QKD Device ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Key ID Length ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! Key ID (variable length) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A =93version=94 seemed prudent, since this may continue to evolve. =93F=94= indicates we have transitioned to Fallback mode, which should only = happen if the OOB key generation underruns. Those are the only things = we would be sacrificing by adopting your format, I think. Shota will = have to weigh in on how eliminating the Fallback flag will affect the = implementation. On the other hand, as long as we=92re adding a new Next Payload ID, I = don=92t see any reason _not_ to include these extra fields. >=20 > It's not clear to me how the actual key is used. Your draft says that > the KE and Nonce payloads are not needed, so I assume that you propose > that the key be used directly as SKEYSEED. No, the bulk encryption key(s) are taken _directly_ from the = QKD-generated random bits. That is, SK_d is the first n bits of QKD material, SK_ai is the next n bits of QKD material, then SK_ar, SK_ei, SK_er, SK_pi, SK_pr are taken in order from the QKD-generated material. Hmm, this probably deserves to be written down. Note that guaranteeing that there are enough bits associated with a = given Key ID and how to avoid wasting any bits that aren=92t used (e.g., = should they appear as KeyID+1 for later use?) we _deliberately_ did not = put into the draft, to avoid unnecessarily constraining the QKD = implementation. Guaranteeing interoperability with different QKD = implementations would require agreeing on that, but IMNSHO that part = belongs to whoever writes the specs to make that happen. > I suggest instead that the > Nonces are retained, and that the key simply replaces the g^ir factor; > that is (for the IKE SA): >=20 > SKEYSEED =3D prf(Ni | Nr, QKD key) We make no use of the prf at all. Randomness comes entirely from the = QKD process. >=20 > You have said that keys MUST NOT be reused. This seems overly > restrictive to me, and opens you to denial of service attacks. An > attacker would be able to very quickly exhaust your keys if each > IKE_SA_INIT exchange used up a key, whether or not the subsequent > authentication phase succeeded. Provided you make use of the nonces = as > I suggest above, you could allow reuse of keys which were part of a > failed exchange (up to a limit): the encrypted part of the subsequent > IKE_AUTH message would use different keys each time. Since we are in > any case making assumptions about the security of the IPsec ciphers, > this seems to leak very little information about the QKD key. Let=92s see, this is an interesting question. I don=92t think there is = any in-band IP-level DoS attack here, but let us think about what = happens when someone attempts to spoof the legitimate partner who = actually holds the KeyID that matches. >=20 > I don't understand the fallback concept. I would have thought that = this > could be negotiated at the time that rekeying (or creating a new Child > SA) was needed. In other words, the end which initiates the rekey can > use a QKD KE payload, and may include SAs with a DH transform > (equivalent to Diffie-Hellman fallback) or no KE transform (equivalent > to Continue fallback). If the initiator is simply making a suggestion > that a fallback transform would be acceptable, so as to save QKD keys, > then I suggest using a Notify payload instead of defining a new one. >=20 > In section 3.1.3, you define a new transform type. As I say above, = this > is not needed if there is general acceptance to define a new KE > Transform Id for QKD; if there is not, then I agree this is necessary. Let=92s talk about these two... > However, you should not define the new Transform Id(s) here: that = should > also be left to IANA. Yes, this list, correct? http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml We need to get the text deferring to IANA written write, so wordsmithing = suggestions welcome. > It is not clear to me how PAK-DH provides any > meaningful additional security, but if you wish to include it in this > document then you need to define clearly how it applies to IKEv2: > RFC5683 is very general and more specific information will be needed = here. Let me check with Shota on this. It may be that it can be deleted with = no significant impact. >=20 > Lastly, something which seems to be missing is a discussion and > specification of QKD key size. Is this assumed to be implicit in the > Key ID? See above, we think this part is out of scope. There are tons of = parameters and specifications that have to be done in order to get to = interoperable QKD devices, and that is WAAAAAAYYY out of scope here. = I=92m pretty sure we can defer this part to the point in time when the = interface between the QKD device and the IPsec gateway (or subsystems, = if the IPsec gateway is integrated into the QKD box) gets written down = in a formal specification. I=92m willing to be persuaded differently, = though. Note that ETSI has an effort to standardize some parts of QKD; = preempting that to make sure that any changes to IPsec & IKE are = documented where they should be, in IETF. > It seems to me that this would be a parameter which needs > negotiation. As such, I would expect to see multiple Transform IDs = for > QKD, each representing a different key size. It may be possible to do > this using an attribute instead, but I think that this would = complicate > negotiation (e.g. the INVALID_KE_PAYLOAD indicates which transform it > prefers, and this doesn't have space for an attribute). >=20 Thanks for the careful read & thoughtful feedback, =97Rod --Apple-Mail=_9C8E43C3-8E27-492F-9C08-0109C6D4A52E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Thanks = Tony, good thoughts.  Let me try to respond, though a couple of = these are really Shota=92s expertise, so if I misrepresent something = hopefully he=92ll correct me.

(Man, it took me much = of the afternoon to read through this, dig through a little code and = some RFCs, and I still haven=92t completely answered all your questions, = but it=92s luau time=85)

On Nov 11, 2014, at 7:03 = PM, Tony Putman <t-ietf@putwet.me.uk> = wrote:


Rod,

I read your draft with interest and have a = number of comments and
questions.  I've not been around long = enough to remember previous
discussions on this (and couldn't find = anything after a cursory search
in archives), so please forgive me if = I'm rehashing previous = arguments.

Most of the prior = discussion was in person or in private email; little to nothing happened = on the ML during the discussion of the -00 draft.  (A couple of the = experts who reviewed it are probably not even on the = ML.)

This time around, we have input from you, = Paul Koning, Greg Troxler (who implemented the first version of this), = and offline, Tero and a couple of senior = people.

Does this mean that there is enough = interest from the WG that this should be a work item?  Would be = happy to have that as an outcome.


The QKD keys (and other similar out-of-band keys) are = associated with
key agreement, so it makes sense to me to reuse the = KE payload.  This
would allow standard notifications and = negotiations to take place.  It
also means that you don't need = to define a new payload and tranform,
only get IDs assigned to cover = OOB key sharing; the way the key
information is packed into the = structure also needs to be = defined.

The KE Payload explicitly = names fields like Diffie-Hellman Group Num.  It=92s pretty closely = tied to D-H.  RFC 5996 says, "The = Key Exchange payload, denoted KE in this document, is used = to exchange Diffie-Hellman = public numbers as part of a Diffie-Hellman key = exchange.=94  I=92m opposed to shoehorning something with = rather different semantics into the same stuff, and adding caveats = like, =93We know that the = normal use is for D-H group number, but we cheat and use it instead to = mean=85=94  That approach = seems likely to lead to maintainability problems down the road, = including on things like having non-D-H items listed in the table of = group numbers.



Possibly the above was suggested previously and = rejected.  If so, I
would suggest producing a new payload which = has exactly the same
structure and behaviour as the KE payload. =  In other words:

=             &n= bsp;          1 =             &n= bsp;     2 =             &n= bsp;     3
   0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
  | Next Payload  |C|  RESERVED =   |         Payload = Length        |
=   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
  |    Key Exchange Method Num =    | =           RESERVED =            |
=   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
  | =             &n= bsp;          QKD = Device ID =             &n= bsp;           &nbs= p;|
=   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
  | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
  ~ =             &n= bsp;           &nbs= p;  Key ID =             &n= bsp;           &nbs= p;   ~
  | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
=   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+

So in this case, your figure = above reuses the KE Payload ID, or not?  I think you=92re asking = for a new Payload ID here (same as we are), just want to be = clear.

I=92m not opposed to the new QKD (or = OOB) Payload hewing fairly closely to the format of KE, but we did add = some fields in our QKD ID Payload.  For the record, here=92s the = current format, from the I-D:

QKD KeyID =
Payload

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Next Payload  !C!  RESERVED   !         Payload Length        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !    version    !F!   flags     !          QKD Device ID        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !         Key ID Length         !                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               !
   !                    Key ID (variable length)                   !
   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A =93version=94 seemed prudent, since this may = continue to evolve.  =93F=94 indicates we have transitioned to = Fallback mode, which should only happen if the OOB key generation = underruns.  Those are the only things we would be sacrificing by = adopting your format, I think.  Shota will have to weigh in on how = eliminating the Fallback flag will affect the = implementation.

On the other hand, as long as = we=92re adding a new Next Payload ID, I don=92t see any reason _not_ to = include these extra fields.


It's not clear to me how the actual key is used. =  Your draft says that
the KE and Nonce payloads are not needed, = so I assume that you propose
that the key be used directly as = SKEYSEED.

No, the bulk encryption key(s) = are taken _directly_ from the QKD-generated random bits.  That = is,
SK_d is the first n bits of QKD material,
SK_ai = is the next n bits of QKD material, then
SK_ar, SK_ei, SK_er, = SK_pi, SK_pr
are taken in order from the QKD-generated = material.

Hmm, this probably deserves to be = written down.

Note that guaranteeing that there = are enough bits associated with a given Key ID and how to avoid wasting = any bits that aren=92t used (e.g., should they appear as KeyID+1 for = later use?) we _deliberately_ did not put into the draft, to avoid = unnecessarily constraining the QKD implementation.  Guaranteeing = interoperability with different QKD implementations would require = agreeing on that, but IMNSHO that part belongs to whoever writes the = specs to make that happen.

 I = suggest instead that the
Nonces are retained, and that the key simply = replaces the g^ir factor;
that is (for the IKE SA):

SKEYSEED =3D= prf(Ni | Nr, QKD key)

We make no use of = the prf at all.  Randomness comes entirely from the QKD = process.


You have said that = keys MUST NOT be reused.  This seems overly
restrictive to me, = and opens you to denial of service attacks.  An
attacker would = be able to very quickly exhaust your keys if each
IKE_SA_INIT = exchange used up a key, whether or not the subsequent
authentication = phase succeeded.  Provided you make use of the nonces as
I = suggest above, you could allow reuse of keys which were part of = a
failed exchange (up to a limit): the encrypted part of the = subsequent
IKE_AUTH message would use different keys each time. =  Since we are in
any case making assumptions about the security = of the IPsec ciphers,
this seems to leak very little information = about the QKD key.

Let=92s see, this = is an interesting question.  I don=92t think there is any in-band = IP-level DoS attack here, but let us think about what happens when = someone attempts to spoof the legitimate partner who actually holds the = KeyID that matches.



I don't understand the fallback concept.  I would = have thought that this
could be negotiated at the time that rekeying = (or creating a new Child
SA) was needed.  In other words, the = end which initiates the rekey can
use a QKD KE payload, and may = include SAs with a DH transform
(equivalent to Diffie-Hellman = fallback) or no KE transform (equivalent
to Continue fallback). =  If the initiator is simply making a suggestion
that a fallback = transform would be acceptable, so as to save QKD keys,
then I suggest = using a Notify payload instead of defining a new one.

In section = 3.1.3, you define a new transform type.  As I say above, this
is = not needed if there is general acceptance to define a new = KE
Transform Id for QKD; if there is not, then I agree this is = necessary.

Let=92s talk about these = two...

However, you should not = define the new Transform Id(s) here: that should
also be left to = IANA.

Yes, this list, = correct?
We need to get the text deferring to IANA written write, so = wordsmithing suggestions welcome.

=  It is not clear to me how PAK-DH provides any
meaningful = additional security, but if you wish to include it in this
document = then you need to define clearly how it applies to IKEv2:
RFC5683 is = very general and more specific information will be needed = here.

Let me check with Shota on this. =  It may be that it can be deleted with no significant = impact.


Lastly, something = which seems to be missing is a discussion and
specification of QKD = key size.  Is this assumed to be implicit in the
Key = ID?

See above, we think this part is out of = scope.  There are tons of parameters and specifications that have = to be done in order to get to interoperable QKD devices, and that is = WAAAAAAYYY out of scope here.  I=92m pretty sure we can defer this = part to the point in time when the interface between the QKD device =  and the IPsec gateway (or subsystems, if the IPsec gateway is = integrated into the QKD box) gets written down in a formal = specification.  I=92m willing to be persuaded differently, = though.

Note that ETSI has an effort to = standardize some parts of QKD; preempting that to make sure that any = changes to IPsec & IKE are documented where they should be, in = IETF.

 It seems to me that = this would be a parameter which needs
negotiation.  As such, I = would expect to see multiple Transform IDs for
QKD, each representing = a different key size.  It may be possible to do
this using an = attribute instead, but I think that this would complicate
negotiation = (e.g. the INVALID_KE_PAYLOAD indicates which transform it
prefers, = and this doesn't have space for an = attribute).


Thanks for the careful = read & thoughtful feedback,

= =97Rod


= --Apple-Mail=_9C8E43C3-8E27-492F-9C08-0109C6D4A52E-- From nobody Wed Nov 12 12:01:44 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4841A1AE0 for ; Wed, 12 Nov 2014 12:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZgzBp6AhqqE for ; Wed, 12 Nov 2014 12:01:31 -0800 (PST) Received: from avasout01.plus.net (avasout01.plus.net [84.93.230.227]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705961AD0C7 for ; Wed, 12 Nov 2014 12:01:10 -0800 (PST) Received: from [192.168.1.2] ([80.229.245.222]) by avasout01 with smtp id Ek151p0034odrNw01k16FT; Wed, 12 Nov 2014 20:01:08 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=ZZGTN6lA c=1 sm=1 tr=0 a=ZDAw9H2lLuf1cmfnewsGHg==:117 a=ZDAw9H2lLuf1cmfnewsGHg==:17 a=0Bzu9jTXAAAA:8 a=rkJuIV0pGx0A:10 a=N659UExz7-8A:10 a=apiPipScAAAA:8 a=EFN36vXRZenWvA8XG9QA:9 a=BkxV86R-1-1OVkTN:21 a=HKNG2hbzHr_FKBup:21 a=pILNOxqGKmIA:10 X-AUTH: putwet+t-ietf:2500 Message-ID: <5463BC80.5020702@putwet.me.uk> Date: Wed, 12 Nov 2014 20:01:04 +0000 From: Tony Putman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Rodney Van Meter References: <14BE57EA00BC0C469E17B5AD698FE67783D07A82@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5462A3C5.8050601@putwet.me.uk> <34767662-9F6F-4C36-8B77-1787FD705157@sfc.wide.ad.jp> In-Reply-To: <34767662-9F6F-4C36-8B77-1787FD705157@sfc.wide.ad.jp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/8Ijr0TVbRBqcyNO3tZMRNRxxe5Y Cc: ipsec , Shota Nagayama , Shigeya Suzuki Subject: Re: [IPsec] IPsec with QKD X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 20:01:41 -0000 Rod, I would class myself as an interested bystander, not one who would actually implement or use a QKD protocol, so I don't know whether this should be a work item or not. Certainly, some of the suggestions I'm making should not be adopted unless it *is* accepted as a work item. On 12/11/14 03:22, Rodney Van Meter wrote: > The KE Payload explicitly names fields like Diffie-Hellman Group Num. > It’s pretty closely tied to D-H. [...] > I’m opposed to shoehorning something with rather > different semantics into the same stuff, and adding caveats like, “We > know that the normal use is for D-H group number, but we cheat and > use it instead to mean…” That approach seems likely to lead to > maintainability problems down the road, including on things like > having non-D-H items listed in the table of group numbers. I don't see this as having different semantics. Certainly the text ties it to D-H, but conceptually it is just a method of exchanging enough information to establish a session key with forward secrecy. I can describe some of the advantages that I see to doing it this way, but I fully agree that this would need broad agreement before going ahead with it. Without such agreement, I suggest a new payload with the same semantics as the KE payload. The main advantage of using the same payload is to do with algorithm negotiation. It's not easy to motivate algorithm negotiation when the underlying assumption is that the peer is known to have a shared QKD key and so presumably already supports this draft, but let me try. Let's suppose that both direct use and PAK-DH are supported. Then the standard IKEv2 approach would be for the initiator to pick one for the initial exchange, but to signal support for both in the SA payload. If the responder does not support the chosen algorithm but will support the other, then it sends back the INVALID_KE_PAYLOAD notification which indicates the transform that it would accept. If we use a different payload, then the same can be achieved by using a different notification, but it is hard to negotiate a choice between current DH key agreement and QKD key agreement (assuming both are acceptable to the initiator). Perhaps this the key point: will the initiator ever be in a position where it does not know that the responder will accept QKD? If so, then it makes sense to indicate support for both DH and QKD, and allow the responder to choose. Although this *can* be done using two different payload types, it is a lot simpler to use the same payload type for both. I have no idea what the answer to this question would be. > So in this case, your figure above reuses the KE Payload ID, or not? > I think you’re asking for a new Payload ID here (same as we are), > just want to be clear. > > I’m not opposed to the new QKD (or OOB) Payload hewing fairly closely > to the format of KE, but we did add some fields in our QKD ID > Payload. [...] At this stage, I'm not taking a position on whether a new Payload ID is used. I'm only saying that the same format can be used either way. In this case, the "Key Exchange Method Num" (which may or may not be identical to the "Diffie-Hellman Group Num" in the KE Payload) is equivalent to your "version": evolving just consists of defining a new Method; also, this will be the same number as is used as the Transform ID (and should be maintained by IANA), so that you can negotiate which version to use. I described previously how I envisage implementing negotiation on fallback policy, so I don't see a need to explicitly include it in the QKD KeyID payload. > [Description of key generation] This is useful information. It answers my question elsewhere about key size: it's defined by the selected algorithms. However, I still think that Ni and Nr should feed into this in order to allow key reuse where the authentication stage has failed. One way to do this would be to define SK_d as the first n bits of the QKD material, then create a keystream as prf+ (SK_d, Ni | Nr | SPIi | SPIr) and xor this with the remaining QKD material to obtain the remaining keys. As far as I can see, this doesn't decrease the entropy of the keys. > [Regarding key material exhaustion] I don’t think there is > any in-band IP-level DoS attack here, but let us think about what > happens when someone attempts to spoof the legitimate partner who > actually holds the KeyID that matches. After some thought, this seems to need an active attacker, so maybe it is not so important. But I also think that the remedy is quite simple (and is already part of IKEv2). > [...] > Thanks for the careful read & thoughtful feedback, My pleasure! I'm afraid that I've skipped some important points, but I want to think more about the question of algorithm negotiation before I address them. I look forward to your thoughts on the matter. Tony From nobody Wed Nov 12 12:12:35 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EED1AD248 for ; Wed, 12 Nov 2014 12:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.595 X-Spam-Level: X-Spam-Status: No, score=-7.595 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, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yta0FvGJL5OI for ; Wed, 12 Nov 2014 12:12:23 -0800 (PST) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169951AD0AE for ; Wed, 12 Nov 2014 12:11:27 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=l5s+w1i1pKikYWSD3IQNRr2u+27INQKcmmpgQkV960d4QYYFf8SsX8Sq 23ktmIZlTEjhHiMlD9rIn5+fgTHnrr0yyj2J1E9yTw/i8t75Aw/pClPuo wVtzrCyUP1KBS+jy0usRXZ+0lurIKKH/jOOM/LqNPApAhZFqmlRdM98hP o=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1415823088; x=1447359088; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lZEYR4FYzzU+o6oZyPp82hhEjthbDwic3J7WZCT1S9A=; b=iqmCs8+OLgBCZVPXC8okpUrP2uUN94vhGNMBZvsZx3+b8v0PEHMYVDpC h/CmLVHfLIzv/aBzpuPZeFIp9LBC8tZlsg32Earx12yjHaWPHI0Tz/RQn HyAPtgNxJog57kpPjvm7Ojnc0rksdIhfFiBK1GgPYKRUQjbVf7Ojv5JxJ U=; X-LoopCount0: from 10.170.28.41 X-IronPort-AV: E=Sophos;i="5.07,370,1413262800"; d="scan'208";a="588285818" From: To: Thread-Topic: [IPsec] IPsec with QKD Thread-Index: AQHP/gwgxJlXedT23kqGoNCWS0yan5xcuEIAgAEXAgCAAALfgA== Date: Wed, 12 Nov 2014 20:11:23 +0000 Message-ID: References: <14BE57EA00BC0C469E17B5AD698FE67783D07A82@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5462A3C5.8050601@putwet.me.uk> <34767662-9F6F-4C36-8B77-1787FD705157@sfc.wide.ad.jp> <5463BC80.5020702@putwet.me.uk> In-Reply-To: <5463BC80.5020702@putwet.me.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.135.92] Content-Type: text/plain; charset="Windows-1252" Content-ID: <98B6FC7BBCAAF640B29D0687C34FB827@dell.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/nBs3KLaAGBu7gq_oLMZ9yLk30-Y Cc: rdv@sfc.wide.ad.jp, ipsec@ietf.org, kurosagi@sfc.wide.ad.jp, shigeya@wide.ad.jp Subject: Re: [IPsec] IPsec with QKD X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 20:12:30 -0000 On Nov 12, 2014, at 3:01 PM, Tony Putman wrote: > ... > Perhaps this the key point: will the initiator ever be in a position > where it does not know that the responder will accept QKD? I would say yes. That would be a policy matter; it could be viewed as a do= wngrade, and if so you may want to block downgrade attacks by insisting on = QKD. But if the QKD channel has failed, your options are (a) don=92t commu= nicate, (b) use a conventional key agreement algorithm, or (c) send in the = clear. (c) is an unlikely choice in practice, but both (a) and (b) are pla= usible depending on policy preferences. What you suggest would enable (b) = in a straightforward way. > ... > At this stage, I'm not taking a position on whether a new Payload ID is > used. I'm only saying that the same format can be used either way. In > this case, the "Key Exchange Method Num" (which may or may not be > identical to the "Diffie-Hellman Group Num" in the KE Payload) is > equivalent to your "version": evolving just consists of defining a new > Method; also, this will be the same number as is used as the Transform > ID (and should be maintained by IANA), so that you can negotiate which > version to use. I described previously how I envisage implementing > negotiation on fallback policy, so I don't see a need to explicitly > include it in the QKD KeyID payload. In a sense, the existing DH group number already carries a kind of method s= elector: we have the MODP flavor of D-H and the ECP one. While they share = basic concepts, they clearly are not the same algorithm. So redefining tha= t field to have that more general meaning certainly seems reasonable. paul From nobody Thu Nov 13 16:13:45 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D671A0104 for ; Thu, 13 Nov 2014 16:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.195 X-Spam-Level: X-Spam-Status: No, score=-93.195 tagged_above=-999 required=5 tests=[ADVANCE_FEE_3_NEW=3.496, BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vd7t7PHqfa5Z for ; Thu, 13 Nov 2014 16:13:34 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DCA81A00F1 for ; Thu, 13 Nov 2014 16:13:34 -0800 (PST) Received: from dhcp-a0a0.meeting.ietf.org (dhcp-a0a0.meeting.ietf.org [31.133.160.160]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BEEF527819B; Fri, 14 Nov 2014 09:13:30 +0900 (JST) From: Rodney Van Meter Content-Type: multipart/alternative; boundary="Apple-Mail=_64FE67D5-B6B4-495F-9ED7-C2A36DCCE1D7" Date: Thu, 13 Nov 2014 14:13:27 -1000 Message-Id: <9882A7B1-DFA7-4963-8904-B2626028B74A@sfc.wide.ad.jp> To: ipsec Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/KvkeB1IE_BQL7UT4d5nMcdygrXI Cc: Rodney Van Meter , Sean Turner , Shota Nagayama , Kathleen Moriarty Subject: [IPsec] IPsec with QKD status X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 00:13:39 -0000 --Apple-Mail=_64FE67D5-B6B4-495F-9ED7-C2A36DCCE1D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 ipsecme-ers, We have managed to catch a number of people in the halls to discuss our IPsec with QKD I-D. Haven't managed to catch Yaron yet. This mail is long. First, an admin summary of where we are, then a technical & writing action item list, and at the bottom a short FYI on the state of QKD, for the curious. Here's where I think we are: * We need this published, so that there is a formal stake in the ground as the growing number of commercial QKD implementations get around to adding a properly engineered IPsec to their supported functionality; existing QKD implementations interface with IP-relevant equipment in an ad hoc manner. (As one person said, "It may be snake oil, but you're entitled to have interoperable snake oil.") * There is no need for Standards Track at the moment; our goal is Experimental RFC as a target for other implementations to aspire to. Therefore, we don't think it's necessary to formally adopt this as a WG item. Taking this through the Independent Stream Editor seems to be the right approach. We have consulted with Kathleen Moriarty, Sean Turner, Paul Hoffman, Nevill Brownlee and a couple of others about this, and they are on board with it. * Even if it's not a WG item, with your permission keeping the discussion public here on the ipsec mailing list seems to be helpful and appropriate. * Several people (Paul Koning, Greg Troxel, Tony Putman, Tero Kivinen) have offered comments on the -01 version. (Sheila Frankel, Alan Mink, Sean Turner offered comments on the -00 version that led to -01.) We will address those in turn; a summary is below. Some of these asked for clarification in the writing, some straightforward changes in packet formats (potentially affecting IANA considerations), a few for significant changes to the semantics. * This will result in a -02 version sometime in the next few weeks as we sort through and address the comments. Our existing open-source implementation corresponds to the -00 draft, but some of these changes are significant enough that we don't want to accept or reject until we have had a chance to at least assess their implementability. * Following the -02, if people on this list are happy, there will certainly be a -03 with wordsmithing. Somewhere around -03, we will probably send to the ISE. My understanding is that he will tap someone to conduct an additional review, and the better we have listened to the folks here the smoother that is likely to go. * Somewhere toward the end of this process, will have to get IANA to assign appropriate IDs. Comments on the above welcome, if we have missed steps or misinterpreted anything. Current action item list, coalescing a couple of prior emails. Had a long F2F session w/ Tero yesterday, some highlights listed here, awaiting full written comments. This list isn't fully orthogonal or prioritized, but obviously some of the suggestions are mutually inconsistent. Conflicts will have to be resolved. Technical questions: * Zeroth suggestion is to broaden to any out of band (OOB) key generation approach (diplomatic pouch being our canonical example). I'm inclined to keep it as focused as possible, but it may well be that by the time we have made the changes proposed, that we are 90% of the way there. * Biggest suggestion is to use the QKD material as SKEYSEED, rather than directly as the bulk encryption keys. We are going to have to think about this, I'm not sure how it will affect what we are trying to accomplish. As long as we avoid the D-H we have accomplished the primary goal, but does using the prf dilute any of the guarantees we get from the QKD itself? e.g., are there vulnerabilities in the prf or known limitations in its lifetime (as with the factoring/discrete logarithm problem of D-H)? I'm not sure. Would it actually add anything to take this approach? I'm not sure. My first inclination is to _not_ adopt this suggestion. * Second biggest suggestion (made by more than one person) is to stick with existing Key Exchange Payload, and just assign a value for the D-H Group Num field to indicate QKD. * Third, fallback is a policy decision, not needed on the wire, perhaps. Just having the right settings in the IKE config should do. * Is there a DoS attack at the IKE negotiation level that can result in us discarding valuable and not yet actually used key material? * Should the nonce be reinstated, and would that allow use to safely reuse some key material? * Can PAK-DH be eliminated? * Should we specify anything about the amount of material matching a KeyID, and what to do we leftover material? * What happens when you have more than one Fallback Payload? Does the prioritization of these need to be documented? * Could a Notify Payload be used instead of a Fallback? * Critical bit is no help against downgrade attack. * Using the keys as material for prf, as in mail, would allow reuse of security proofs. * Can combine device ID, key ID into one undifferentiated field, then add annex saying what our implementation does. * Proposed Payload format is too long and too complex, simpler is preferred. Editing TODO: * Fix IANA-related language * Clarify non-use of prf, order in which keys are extracted from KeyID SK_d is the first n bits of QKD material, SK_ai is the next n bits of QKD material, then SK_ar, SK_ei, SK_er, SK_pi, SK_pr are taken in order from the QKD-generated material. (assuming above change is not adopted) Source matching the -00 draft is available at http://aqua.sfc.wide.ad.jp/research/ipsecwithqkd.html This will be updated around the time we submit -02. Status of QKD: * Several commercial implementations exist, integration into classical networks is still work in progress in the various testbeds, largely being done by (ahem) experimental physicists rather than experienced Internet people. * ETSI was pushing to standardize various physical elements, effort stalled at the moment. * Metro area networks continue to grow; exist in Japan, Spain, China, = South Africa, other places. * China announced Beijing-Shanghai network for 2016 = http://www.scmp.com/news/china/article/1631479/china-launch-hack-proof-qua= ntum-communication-network-2016 * Battelle doing Columbus-Washington link = http://www.battelle.org/our-work/national-security/tactical-systems/quantu= m-key-distribution * LANL trying for testbed for securing infrastructure * Another very large investment (tens of millions) underway in Europe * Quantum repeaters are in experimental development, don't fully exist yet but would overcome distance limitations (and enable non-QKD applications of quantum states) * Satellite-based QKD also in development, experiment using the International Space Station has been proposed, don't think it has been scheduled yet. If you read this far, thanks. Comments welcome! I'm flying out tonight, but am available in the session right after ipsecme. Otherwise, find us (Shota & me) online. =97Rod Rodney Van Meter associate professor, Faculty of Environment and Information Studies, = Keio University, Japan rdv@sfc.wide.ad.jp personal: http://web.sfc.keio.ac.jp/~rdv/ AQUA Group: http://aqua.sfc.wide.ad.jp/ Murai Lab: http://www.sfc.wide.ad.jp/IRL/ GIGA: http://ic.sfc.keio.ac.jp/ Quantum Networking: = http://www.wiley.com/WileyCDA/WileyTitle/productCd-1848215371.html http://discourse.quantumnetworks.org/ --Apple-Mail=_64FE67D5-B6B4-495F-9ED7-C2A36DCCE1D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
ipsecme-ers,

We have = managed to catch a number of people in the halls to = discuss
our IPsec with QKD I-D.  Haven't managed to catch = Yaron yet.

This mail is long.  First, an = admin summary of where we are, then a
technical & writing = action item list, and at the bottom a short FYI on
the state = of QKD, for the curious.

Here's where I think = we are:

* We need this published, so that there = is a formal stake in the
  ground as the growing number = of commercial QKD implementations get
  around to adding = a properly engineered IPsec to their supported
  = functionality; existing QKD implementations interface = with
  IP-relevant equipment in an ad hoc manner. =  (As one person said, "It
  may be snake oil, but = you're entitled to have interoperable snake
  = oil.")
* There is no need for Standards Track at the moment; = our goal is
  Experimental RFC as a target for other = implementations to aspire to.
  Therefore, we don't think = it's necessary to formally adopt this as a
  WG item. =  Taking this through the Independent Stream Editor seems = to
  be the right approach.  We have consulted with = Kathleen Moriarty,
  Sean Turner, Paul Hoffman, Nevill = Brownlee and a couple of others
  about this, and they = are on board with it.
* Even if it's not a WG item, with your = permission keeping the
  discussion public here on the = ipsec mailing list seems to be helpful
  and = appropriate.
* Several people (Paul Koning, Greg Troxel, Tony = Putman, Tero Kivinen)
  have offered comments on the -01 = version.  (Sheila Frankel, Alan
  Mink, Sean Turner = offered comments on the -00 version that led to
  -01.) =  We will address those in turn; a summary is below.  Some = of
  these asked for clarification in the writing, some = straightforward
  changes in packet formats (potentially = affecting IANA
  considerations), a few for significant = changes to the semantics.
* This will result in a -02 version = sometime in the next few weeks as
  we sort through and = address the comments.  Our existing open-source
  = implementation corresponds to the -00 draft, but some of = these
  changes are significant enough that we don't want = to accept or
  reject until we have had a chance to at = least assess their
  implementability.
* = Following the -02, if people on this list are happy, there = will
  certainly be a -03 with wordsmithing. =  Somewhere around -03, we will
  probably send to = the ISE.  My understanding is that he will tap
  = someone to conduct an additional review, and the better we = have
  listened to the folks here the smoother that is = likely to go.
* Somewhere toward the end of this process, will = have to get IANA to
  assign appropriate = IDs.

Comments on the above welcome, if we have = missed steps or
misinterpreted = anything.

Current action item list, coalescing = a couple of prior emails.  Had a
long F2F session w/ Tero = yesterday, some highlights listed here,
awaiting full written = comments.  This list isn't fully orthogonal = or
prioritized, but obviously some of the suggestions are = mutually
inconsistent.  Conflicts will have to be = resolved.

Technical = questions:

* Zeroth suggestion is to broaden to = any out of band (OOB) key
  generation approach = (diplomatic pouch being our canonical example).
  I'm = inclined to keep it as focused as possible, but it may well = be
  that by the time we have made the changes proposed, = that we are 90%
  of the way there.
* Biggest = suggestion is to use the QKD material as SKEYSEED, = rather
  than directly as the bulk encryption keys. =  We are going to have to
  think about this, I'm not = sure how it will affect what we are trying
  to = accomplish.  As long as we avoid the D-H we have accomplished = the
  primary goal, but does using the prf dilute any of = the guarantees we
  get from the QKD itself?  e.g., = are there vulnerabilities in the prf
  or known = limitations in its lifetime (as with the = factoring/discrete
  logarithm problem of D-H)?  I'm = not sure.  Would it actually add
  anything to take = this approach?  I'm not sure.  My first = inclination
  is to _not_ adopt this = suggestion.
* Second biggest suggestion (made by more than one = person) is to stick
  with existing Key Exchange Payload, = and just assign a value for the
  D-H Group Num field to = indicate QKD.
* Third, fallback is a policy decision, not = needed on the wire,
  perhaps.  Just having the = right settings in the IKE config should
  do.
* = Is there a DoS attack at the IKE negotiation level that can = result
  in us discarding valuable and not yet actually = used key material?
* Should the nonce be reinstated, and would = that allow use to safely
  reuse some key = material?
* Can PAK-DH be eliminated?
* Should we = specify anything about the amount of material matching = a
  KeyID, and what to do we leftover = material?
* What happens when you have more than one Fallback = Payload?  Does the
  prioritization of these need to = be documented?
* Could a Notify Payload be used instead of a = Fallback?
* Critical bit is no help against downgrade = attack.
* Using the keys as material for prf, as in mail, = would allow reuse of
  security proofs.
* Can = combine device ID, key ID into one undifferentiated field, = then
  add annex saying what our implementation = does.
* Proposed Payload format is too long and too complex, = simpler is
  preferred.

Editing = TODO:

* Fix IANA-related language
* = Clarify non-use of prf, order in which keys are extracted from = KeyID
  SK_d is the first n bits of QKD = material,
  SK_ai is the next n bits of QKD material, = then
  SK_ar, SK_ei, SK_er, SK_pi, SK_pr
  = are taken in order from the QKD-generated material.
  = (assuming above change is not adopted)

Source = matching the -00 draft is available at
This will be = updated around the time we submit -02.

Status = of QKD:
* Several commercial implementations exist, = integration into classical
  networks is still work in = progress in the various testbeds, largely
  being done by = (ahem) experimental physicists rather than experienced
  = Internet people.
* ETSI was pushing to standardize various = physical elements, effort
  stalled at the = moment.
* Metro area networks continue to grow; exist in = Japan, Spain, China, South Africa, other places.
* China = announced Beijing-Shanghai network for 2016
* LANL = trying for testbed for securing infrastructure
* Another very = large investment (tens of millions) underway in Europe
* = Quantum repeaters are in experimental development, don't fully = exist
  yet but would overcome distance limitations (and = enable non-QKD
  applications of quantum = states)
* Satellite-based QKD also in development, experiment = using the
  International Space Station has been = proposed, don't think it has been
  scheduled = yet.

If you read this far, thanks. =  Comments welcome!  I'm flying out
tonight, but am = available in the session right after ipsecme.
Otherwise, find = us (Shota & me) online.

= =97Rod



Rodney Van = Meter
associate professor, Faculty of Environment and = Information Studies, Keio University, Japan
=
=


= --Apple-Mail=_64FE67D5-B6B4-495F-9ED7-C2A36DCCE1D7-- From nobody Thu Nov 13 17:02:54 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890C31A1AC4 for ; Thu, 13 Nov 2014 17:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 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, MANGLED_TOOL=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rm6h_DFOwE4l for ; Thu, 13 Nov 2014 17:02:38 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2601A1AB7 for ; Thu, 13 Nov 2014 17:02:37 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id l15so1208456wiw.10 for ; Thu, 13 Nov 2014 17:02:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=UeSdnPY5bkd9KJ6qofkkvZZZLGVlccn5ysmNkbxoDxc=; b=jlCKBMU/jvsj1xXxOzgQczk76BYBRfUyNGId0ArbDb7H42254eiTLpVWhuA57UzsdF GX3OFXSrPt0AitU085dIl7RlWc4L3R/MS5PCmNhv8lOMJMlJ6RbsUPbX+FvtSlXGE3s1 vWaAHVwEd+hxLF7O7RVzFVgpSKyjnJRwftFkTs6SxMEakv1xTcfHAd+TL6gOT5Hw0BVN QovqvO1Bh+kVnuM0t8oYMu9zjnonIZAZ0IzOKSN79GfTnPCbMQNVFvbp6Dwem2DI49Zc kVjoq4maTk3kbXAEIcXMze+G6Nvx6aTtahHMjI+rIthCb2aNjtNVErNiMw8FInvKu1Gg aeyg== X-Received: by 10.194.189.81 with SMTP id gg17mr8885877wjc.115.1415926956742; Thu, 13 Nov 2014 17:02:36 -0800 (PST) Received: from [10.0.0.4] (bzq-79-176-2-1.red.bezeqint.net. [79.176.2.1]) by mx.google.com with ESMTPSA id wm6sm37600497wjb.5.2014.11.13.17.02.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Nov 2014 17:02:36 -0800 (PST) Message-ID: <546554AA.1070503@gmail.com> Date: Fri, 14 Nov 2014 03:02:34 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Rodney Van Meter , ipsec References: <9882A7B1-DFA7-4963-8904-B2626028B74A@sfc.wide.ad.jp> In-Reply-To: <9882A7B1-DFA7-4963-8904-B2626028B74A@sfc.wide.ad.jp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/qzZH5I6CSA2y5H3l5Kb4uogbjMo Cc: Kathleen Moriarty , Sean Turner , Shota Nagayama Subject: Re: [IPsec] IPsec with QKD status X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 01:02:40 -0000 Hi Rod, Two quick comments: - I am fine with the Experimental/ISE route. - I support the SKEYSEED idea. It makes sense as a single point of integration into the protocol, so that if we ever specify a different way of generating key material, it would not need to be re-specified for QKD. Of course generation of key material depends on PRF algorithms that might get weaker over time, but since we're going to use the key material for symmetric algorithms anyway, I think this is appropriate - the strength of PRF can be correlated to key length of symmetric encryption/MAC algorithms. Thanks, Yaron On 11/14/2014 02:13 AM, Rodney Van Meter wrote: > ipsecme-ers, > > We have managed to catch a number of people in the halls to discuss > our IPsec with QKD I-D. Haven't managed to catch Yaron yet. > > This mail is long. First, an admin summary of where we are, then a > technical & writing action item list, and at the bottom a short FYI on > the state of QKD, for the curious. > > Here's where I think we are: > > * We need this published, so that there is a formal stake in the > ground as the growing number of commercial QKD implementations get > around to adding a properly engineered IPsec to their supported > functionality; existing QKD implementations interface with > IP-relevant equipment in an ad hoc manner. (As one person said, "It > may be snake oil, but you're entitled to have interoperable snake > oil.") > * There is no need for Standards Track at the moment; our goal is > Experimental RFC as a target for other implementations to aspire to. > Therefore, we don't think it's necessary to formally adopt this as a > WG item. Taking this through the Independent Stream Editor seems to > be the right approach. We have consulted with Kathleen Moriarty, > Sean Turner, Paul Hoffman, Nevill Brownlee and a couple of others > about this, and they are on board with it. > * Even if it's not a WG item, with your permission keeping the > discussion public here on the ipsec mailing list seems to be helpful > and appropriate. > * Several people (Paul Koning, Greg Troxel, Tony Putman, Tero Kivinen) > have offered comments on the -01 version. (Sheila Frankel, Alan > Mink, Sean Turner offered comments on the -00 version that led to > -01.) We will address those in turn; a summary is below. Some of > these asked for clarification in the writing, some straightforward > changes in packet formats (potentially affecting IANA > considerations), a few for significant changes to the semantics. > * This will result in a -02 version sometime in the next few weeks as > we sort through and address the comments. Our existing open-source > implementation corresponds to the -00 draft, but some of these > changes are significant enough that we don't want to accept or > reject until we have had a chance to at least assess their > implementability. > * Following the -02, if people on this list are happy, there will > certainly be a -03 with wordsmithing. Somewhere around -03, we will > probably send to the ISE. My understanding is that he will tap > someone to conduct an additional review, and the better we have > listened to the folks here the smoother that is likely to go. > * Somewhere toward the end of this process, will have to get IANA to > assign appropriate IDs. > > Comments on the above welcome, if we have missed steps or > misinterpreted anything. > > Current action item list, coalescing a couple of prior emails. Had a > long F2F session w/ Tero yesterday, some highlights listed here, > awaiting full written comments. This list isn't fully orthogonal or > prioritized, but obviously some of the suggestions are mutually > inconsistent. Conflicts will have to be resolved. > > Technical questions: > > * Zeroth suggestion is to broaden to any out of band (OOB) key > generation approach (diplomatic pouch being our canonical example). > I'm inclined to keep it as focused as possible, but it may well be > that by the time we have made the changes proposed, that we are 90% > of the way there. > * Biggest suggestion is to use the QKD material as SKEYSEED, rather > than directly as the bulk encryption keys. We are going to have to > think about this, I'm not sure how it will affect what we are trying > to accomplish. As long as we avoid the D-H we have accomplished the > primary goal, but does using the prf dilute any of the guarantees we > get from the QKD itself? e.g., are there vulnerabilities in the prf > or known limitations in its lifetime (as with the factoring/discrete > logarithm problem of D-H)? I'm not sure. Would it actually add > anything to take this approach? I'm not sure. My first inclination > is to _not_ adopt this suggestion. > * Second biggest suggestion (made by more than one person) is to stick > with existing Key Exchange Payload, and just assign a value for the > D-H Group Num field to indicate QKD. > * Third, fallback is a policy decision, not needed on the wire, > perhaps. Just having the right settings in the IKE config should > do. > * Is there a DoS attack at the IKE negotiation level that can result > in us discarding valuable and not yet actually used key material? > * Should the nonce be reinstated, and would that allow use to safely > reuse some key material? > * Can PAK-DH be eliminated? > * Should we specify anything about the amount of material matching a > KeyID, and what to do we leftover material? > * What happens when you have more than one Fallback Payload? Does the > prioritization of these need to be documented? > * Could a Notify Payload be used instead of a Fallback? > * Critical bit is no help against downgrade attack. > * Using the keys as material for prf, as in mail, would allow reuse of > security proofs. > * Can combine device ID, key ID into one undifferentiated field, then > add annex saying what our implementation does. > * Proposed Payload format is too long and too complex, simpler is > preferred. > > Editing TODO: > > * Fix IANA-related language > * Clarify non-use of prf, order in which keys are extracted from KeyID > SK_d is the first n bits of QKD material, > SK_ai is the next n bits of QKD material, then > SK_ar, SK_ei, SK_er, SK_pi, SK_pr > are taken in order from the QKD-generated material. > (assuming above change is not adopted) > > Source matching the -00 draft is available at > http://aqua.sfc.wide.ad.jp/research/ipsecwithqkd.html > This will be updated around the time we submit -02. > > Status of QKD: > * Several commercial implementations exist, integration into classical > networks is still work in progress in the various testbeds, largely > being done by (ahem) experimental physicists rather than experienced > Internet people. > * ETSI was pushing to standardize various physical elements, effort > stalled at the moment. > * Metro area networks continue to grow; exist in Japan, Spain, China, > South Africa, other places. > * China announced Beijing-Shanghai network for 2016 > http://www.scmp.com/news/china/article/1631479/china-launch-hack-proof-quantum-communication-network-2016 > * Battelle doing Columbus-Washington link > http://www.battelle.org/our-work/national-security/tactical-systems/quantum-key-distribution > * LANL trying for testbed for securing infrastructure > * Another very large investment (tens of millions) underway in Europe > * Quantum repeaters are in experimental development, don't fully exist > yet but would overcome distance limitations (and enable non-QKD > applications of quantum states) > * Satellite-based QKD also in development, experiment using the > International Space Station has been proposed, don't think it has been > scheduled yet. > > If you read this far, thanks. Comments welcome! I'm flying out > tonight, but am available in the session right after ipsecme. > Otherwise, find us (Shota & me) online. > > —Rod > > > > Rodney Van Meter > associate professor, Faculty of Environment and Information Studies, > Keio University, Japan > rdv@sfc.wide.ad.jp > personal: http://web.sfc.keio.ac.jp/~rdv/ > AQUA Group: http://aqua.sfc.wide.ad.jp/ > Murai Lab: http://www.sfc.wide.ad.jp/IRL/ > GIGA: http://ic.sfc.keio.ac.jp/ > Quantum Networking: > http://www.wiley.com/WileyCDA/WileyTitle/productCd-1848215371.html > http://discourse.quantumnetworks.org/ > > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Thu Nov 13 20:15:10 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4371A6EE1 for ; Thu, 13 Nov 2014 20:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ca8Pd0nLdD5m for ; Thu, 13 Nov 2014 20:15:01 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7495A1A1BB1 for ; Thu, 13 Nov 2014 20:15:01 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 13673817C1 for ; Thu, 13 Nov 2014 23:15:00 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1415938500; bh=RYkqeFiFfCm+/nTa3ISscQKormiAV/bGC2W0smu01HU=; h=Date:From:To:Subject; b=UUxEOWnSaJPJ6IxTAPBFzRs+fRPun1zt8qMraf6dTI1EMbveIz9LzoLShm/J5PUDy 5PsB902pFEA3FXiu70ychL9QCaWLQnlyTR7UsyjiQrwygQFWwayQIM0XUVEnN4wIib pJ5AD3nf8mwSCBm8FHh0nIQO3vXmwYbP9RyiWJQU= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sAE4ExMu028701 for ; Thu, 13 Nov 2014 23:14:59 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 13 Nov 2014 23:14:59 -0500 (EST) From: Paul Wouters To: ipsec Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/kJxPNUF1Tm7-cqb-zMxBSuXjoIw Subject: [IPsec] IETF-91 minutes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 04:15:08 -0000 IPsec ME minutes IETF 91 PaulH: brief status report (see slides, new RFC's 7321, 7296, 7383, signature-auth in queue) Yaov: Someone found a way to make TCP connections inside tunnels fail, but using PACKET_TOO_BIG messages to the gateway that make the tunnel MTU go below the minimum for the IP version by reducing the ESP PMTU down to the minimum. Yoav: sector list[?] there is a paper? Valery on NULL auth: - intial contact clarified (must be ignored) - early code point requested - no formal security proof - channel binding two peers can authenticate each other out of band if needed. not an issue - more security considerations are needed Paul Wouters offered help PaulW: exposing ports can be desirable for some Tero: can use transport mode to reveal those Tero: waiting for this meeting for early code point id_null or empty id can be changed without much problems auth_none method won't change so that is safe too. if not speak up NOW PaulH: any major change to be submitted? no. ok tero send to IANA. PaulH: security proof is not required. Yaron backed down on requiring it. Dan Harkins: been beaten on head for lack fo security proof. typically not required in ietf This follows usual path. PaulH: mailing list said no channel binding Brian Weis: Ok I wont ask for formal security proof PaulW: there are places in code where we thought "this is fine becaus it is only authenticated". We need to revisit those decisions now. Yaron: I am mostly worried about people assuming that one-sided auth is as good as TLS, which may not be true when investigated formally. PaulH: WGLC soonish PaulH: who else feels confident (2 more) (besides, Paul, Valery) Yaron: for the record, I disagree with my esteemed co-chair. OK with code assignment, not yet OK with LC. PaulH: chairs will discuss Valery: D. Migault and me published draft-clone-ike-sa Please look at this for adoption/rejection PaulH: we'll ask for interest on the list Yoav: Defending IKE Responders Against Denial of Service attacks" presentation Yoav: anti-ddos slides Michael Richardson: should we be changing our scope for this document due to null_auth? Yoav: out of scope for now in the draft. We should think about it. PaulH: we can ask that question later. Yoav: for now we assume attacker cannot complete AUTH Yoav: attacker receiving ike_init can cheaply sent nonsense AUTH, causing lots of work on responder Yoav: even more complex, attacker send AUTH that decrypts OK, then fails Yoav: basic defense, stateless cookies. does not stop attacks with return routability Yoav: rate limiting of half-open based on v4 address or v6 range Yoav: if half-open sa db is attacked, reduce retention time. usually 3-5 seconds seems ok value Yoav: puzzles for attackers that can send IKE_AUTH. Yoav: puzzle now based on proof-of-work in bitcoin blockchain (see slide) Tero: known ip's to use puzzles to proof (eg known home workers ip) Valery: different puzzles for different IPs? [could not understand much] Valery: crypto agility missing Yoav: we can require more digits, more zeroes, if sha2 would become weaker / easier to solve Brian Wise: do we want a registry of puzzles and only do one now? Brian Wise: you changed puzzle, but mechanism is still the same ? Yoav: previous one was responder gave initiator most of the cookie. But it was patented, so switched to current system. is used in bitcoin, no one has sued there yet Brain Wise: if client can't do puzzle there are out in the last scenario? Yoav: yes, that's why you do this last. it will affect legitimate clients PaulH: that's why the draft now statesm ore about DOS and not just puzzle Rene Hummen: the puzzle offsets connection establishment. doesn't it just moves the [problem point] Rene: you are just delaying the problem. Yoav: No, we are reducing the rate of the botnet as a whole Yaron: with a 5/sec rate limit, the puzzle is meaningless, because attackers are desktops and so the puzzle is worth 0.1 sec or less. I still support puzzles, because they mitigate a botnet that's attacking *multiple* uncoordinated gateways PaulW: asking if draft says something about making it easier for reconnecting puzzle solvers to help them not empty their battery Yoav: use the ticket RFC for that. Ron van Meter: What is the effect on network load going to be? I think only a factor 2 or 3, so modest Yoav: it reduces the number of packets the attackers can really (usefully?) send. PaulH: few minutes left Rod van Meter: QKD draft revived from a couple of years ago. Got a lot of responses on the mailing list. we're planning this to the independant stream. we appreciate the feedback we got so far. PaulH: we are not asking for WG daoption. Independant submission is outside the ietf. only thing that will happen is that they will ask IESG if this an endrun around something. It is okay to discuss on mailing list. Rod: couple of Q's left, feedback sooner rather than later wouldbe good. Tero: I'd rather have it as individual draft. it is still modification to IKE, would still like IETF to look at it. PaulH: nothing prevents us to pull it in later, especially if we have concerns Kathleen Moriarty: (our AD): was there a call for adoption? PaulH: eons ago, no interest Kathleen: has that changed? Tero seems to think so? Tero: I have interest in everything..... even if experimental, doesnt need to be in WG because there are not that many people planning on implementing/modifying it. Not much point to go into WG. PaulH: Kathleen, Yaron and I should talk and come up with some words on this Kathleen: I do need more information from WG to see what is the right path. Implementations would be another factor. we do need to hear from everyone. PaulH: we'll talk about how to ask the WG. Kathleen: Lets do that within the next few weeks Rod: just to be clear, we are okay with either. end of meeting From nobody Tue Nov 25 12:08:13 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDC31A87E3 for ; Tue, 25 Nov 2014 12:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGxiKcaEa2Zd for ; Tue, 25 Nov 2014 12:06:14 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (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 CEDAE1A87E7 for ; Tue, 25 Nov 2014 12:06:13 -0800 (PST) Received: from [10.20.30.90] (142-254-17-143.dsl.dynamic.fusionbroadband.com [142.254.17.143]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sAPK6CnT030205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Nov 2014 13:06:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-143.dsl.dynamic.fusionbroadband.com [142.254.17.143] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> Date: Tue, 25 Nov 2014 12:06:11 -0800 To: IPsecME WG Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/3rx4jWnkCLzvS8ii5lrEY26Ofn4 Subject: [IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 20:06:16 -0000 Greetings again. There is a small emerging industry of crypto solutions = that transmit keys using Quantum Key Distribution (QKD), and then use = those keys for classical high-speed encryption. Several such solutions = are using IKE, and there is a perceived need to standardize this usage. = If so, that standardization should be done in this Working Group. If you agree with the need to standardize this usage, and believe that = draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good starting = place for that standardization, and are willing to review and contribute = text to the document if it is adopted by the WG, please say so on the = list. This WG has a history of adopting documents but then not having = enough reviewers for us to feel confident that we are making a good = standard, so we need to see a reasonable number of actively interested = people before we adopt the document. If it is not adopted, the authors = can ask for it to be published as an RFC through individual submission = or by the Independent Submissions Editor. Please reply by December 8, 2015. --Paul Hoffman and Yaron Sheffer= From nobody Tue Nov 25 12:08:15 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE5F1A87E3 for ; Tue, 25 Nov 2014 12:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdeRu0moXsXA for ; Tue, 25 Nov 2014 12:06:35 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (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 8B2A31A87D2 for ; Tue, 25 Nov 2014 12:06:35 -0800 (PST) Received: from [10.20.30.90] (142-254-17-143.dsl.dynamic.fusionbroadband.com [142.254.17.143]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sAPK6CnU030205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Nov 2014 13:06:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-143.dsl.dynamic.fusionbroadband.com [142.254.17.143] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 25 Nov 2014 12:06:34 -0800 To: IPsecME WG Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/O2yfVJAmaTeRWpDILU9gr0NsyFE Subject: [IPsec] Survey for WG interest in adopting draft-mglt-ipsecme-clone-ike-sa X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 20:06:37 -0000 Greetings again. The "Clone IKE SA" proposal tries to optimize IKE SA = setup in cases where VPN gateways have multiple interfaces and want to = establish different SAs on the different interfaces without having to = repeat the IKE authentication. Instead, they could clone a single IKE SA = multiple times, and then move it to different interfaces using MOBIKE. If you agree with the need to standardize this usage, and believe that = draft-mglt-ipsecme-clone-ike-sa is likely to be a good starting place = for that standardization, and are willing to review and contribute text = to the document if it is adopted by the WG, please say so on the list. = This WG has a history of adopting documents but then not having enough = reviewers for us to feel confident that we are making a good standard, = so we need to see a reasonable number of actively interested people = before we adopt the document. If it is not adopted, the authors can ask = for it to be published as an RFC through individual submission or by the = Independent Submissions Editor. Please reply by December 8, 2015. --Paul Hoffman and Yaron Sheffer= From nobody Tue Nov 25 19:05:57 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647691A8795 for ; Tue, 25 Nov 2014 19:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qPpE3hBy9RI for ; Tue, 25 Nov 2014 19:05:49 -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 D4AB31A878E for ; Tue, 25 Nov 2014 19:05:48 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7714E2002A for ; Tue, 25 Nov 2014 22:08:40 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 72708637F5; Tue, 25 Nov 2014 22:05:46 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 55D9A63740 for ; Tue, 25 Nov 2014 22:05:46 -0500 (EST) From: Michael Richardson To: IPsecME WG In-Reply-To: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> References: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-SaCKrNSSu7pvUl-pkvhm8vw5sI Subject: Re: [IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 03:05:53 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Paul Hoffman wrote: > If you agree with the need to standardize this usage, and believe that > draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good starting > place for that standardization, and are willing to review and > contribute text to the document if it is adopted by the WG, please say > so on the list. This WG has a history of adopting documents but then > not having enough reviewers for us to feel confident that we are maki= ng > a good standard, so we need to see a reasonable number of actively > interested people before we adopt the document. If it is not adopted, > the authors can ask for it to be published as an RFC through individu= al > submission or by the Independent Submissions Editor. I think ISE is the right way. My comments start with the first paragraph: This document describes modifications to IKEv2 to use keys created via QKD for the Internet Key Exchange IKE_SA[RFC4306], the key agreement protocol for IPsec[RFC4301] . With the exception of the use of the new Payloads defined below and the removal of the Diffie- Hellman key agreement information, IKEv2 system operates in standard fashion. It seems like if one is going to use the QKD to distribute keys for other than direct use by IPsec, then the major reason for doing this is to get PF= S. As such, why remove the DH? It seems like the QKD should just provide a PSK-like authentication. Some of the explanation seems to be: However, existing IPsec/IKE implementations actually have a lower data secrecy lifetime, due to their dependence on Diffie-Hellman key agreement. The security of Diffie-Hellman depends on the difficulty of the factoring problem, which remains uncertain; factoring may prove vulnerable either to theoretical advances in algorithms, or the deployment of large-scale quantum computers. An eavesdropper who records encrypted packets today can store those packets, and decrypt them later by discovering the key, when it becomes technically feasible to do so. I'm not entirely sure I understand how to QKD key material gets mixed in wi= th the nonces, etc. to form keys; but that's probably because I read too quickly. I vote for ISE. Give them whatever numbers they need, and let's hear back how it goes... =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVHVDh4CLcPvd0N1lAQL/bwgAraJaTKLyFzrCj5Q8/xiDn96/ZbNRiZZE r+77qTUSjwJMZt3VTm5kfBnxoU5tHPbNG/49/2mzm0pA1bEh4rR2JS15fTGabNFa RYjhRZ2eutYdotsMT29mD+4IoSSq44GXR9Mzv+N7I1p72GjWEGohkzVJlRVIOiwd yMSXtD4VkwxN9b/ZSGFy8yXiLjM7d+WijRHLLhKxjXyzPcb2QXXC+ZijteWP8nc6 wfwT5mZ5ppGELGooa7BjXGhn9JhTWpju6NjRXkBbAmIBLzMbwujqqb+gzFZ7Amz4 /csDdpsudhOMVSCWHygdrxhk5eBUzQYXqJghuHu2JdnWN92CVqYrQA== =t9TD -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 26 04:01:32 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83F11A1BBC for ; Wed, 26 Nov 2014 04:01:30 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1S0ib7Dpa8iZ for ; Wed, 26 Nov 2014 04:01:29 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24DFE1A8A4E for ; Wed, 26 Nov 2014 04:01:27 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y19so3522873wgg.0 for ; Wed, 26 Nov 2014 04:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=gZWpN3gyxuq9p5dzqWqj5WvYxfOi3iEYYJRiX+EVWzQ=; b=N+gHs+C+x0wGDgpoKhvoqZarKeKGLlOPiOqFrxWu/DPBEB8XusSEUs+ocViVCU7DMK 0YgmkoiENE7NQK/nN7ZGWaJAsNMfu8JnkpOQh8ePD2nkGc5gjeTaWDDRxeoXvF6e7g39 HJBlVRyW9ZyTcFHoDJWHcVbR+uxhZyU2J7++HJlwXpnOK5LRklV7s+nPOQJZ8AnqK6S8 b/h55pYl3fETnaQ6GLXrJsxlKfGyySVtuff6QdaQjRn4/twQvhwDibu4syirabTvYW5Q YZbg1qsqX34JpAa+HQf1K/UZ9fYFFgHMAuU8+Y6w7katw0AQ5SvFZL9KSTC99D94Csks fRJA== X-Received: by 10.181.13.7 with SMTP id eu7mr26109763wid.72.1417003285712; Wed, 26 Nov 2014 04:01:25 -0800 (PST) Received: from [172.24.251.68] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id fm10sm6061363wjc.43.2014.11.26.04.01.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Nov 2014 04:01:24 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_9A68E53C-DA9E-47F3-9B5E-B4973070B925" Message-Id: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> Date: Wed, 26 Nov 2014 14:01:22 +0200 To: ipsec Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/nElzuNOFYa1Twx9pjDQavTeqoLw Subject: [IPsec] DDoS Protection issue #226 - Do we need puzzles at all? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 12:01:31 -0000 --Apple-Mail=_9A68E53C-DA9E-47F3-9B5E-B4973070B925 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/226 = Hi. I think this one we should get out of the way first. Puzzles limit the rate at which a particular host can create half-open = SAs. If the puzzle takes 2 seconds to solve then a particular initiator = (whether legitimate initiator, or a node in a bot-net) can create at = most 1 half-open SA every 2 seconds. Another way to achieve the same goal is to limit the half-open SA = lifetime to 10 seconds and have a hard limit of 5 concurrent half-open = SAs per peer. Sure, the attacker will be able to open 5 half-open SAs = within one second, but will then be rejected for the next 9. So why do I think we still need puzzles? I don=E2=80=99t like hard limits. Hard limits allow a very easy form of = DoS. If everyone in this hotel is behind a single NAT device, then = it=E2=80=99s fairly easy for me to create multiple half-open SAs from my = room until I hit the hard limit. After that, everyone will be = effectively blocked from initiating. So while this is not a =E2=80=9Cnobod= y can connect to victim gateway=E2=80=9D attack, it is =E2=80=9Cnobody = in this hotel can connect to victim gateway=E2=80=9D. Soft limits are = better. With soft limits you start dishing out puzzles when you reach a = certain threshold, and you never completely block. That=E2=80=99s why I think puzzles should stay. Yoav= --Apple-Mail=_9A68E53C-DA9E-47F3-9B5E-B4973070B925 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/226

Hi.

I think this one we = should get out of the way first.

Puzzles limit the rate at which a = particular host can create half-open SAs. If the puzzle takes 2 seconds = to solve then a particular initiator (whether legitimate initiator, or a = node in a bot-net) can create at most 1 half-open SA every 2 = seconds.

Another= way to achieve the same goal is to limit the half-open SA lifetime to = 10 seconds and have a hard limit of 5 concurrent half-open SAs per peer. = Sure, the attacker will be able to open 5 half-open SAs within one = second, but will then be rejected for the next 9.
So why do I think we still need = puzzles?

I = don=E2=80=99t like hard limits. Hard limits allow a very easy form of = DoS. If everyone in this hotel is behind a single NAT device, then = it=E2=80=99s fairly easy for me to create multiple half-open SAs from my = room until I hit the hard limit. After that, everyone will be = effectively blocked from initiating. So while this is not a =E2=80=9Cnobod= y can connect to victim gateway=E2=80=9D attack, it is =E2=80=9Cnobody = in this hotel can connect to victim gateway=E2=80=9D.  Soft limits = are better. With soft limits you start dishing out puzzles when you = reach a certain threshold, and you never completely block.

That=E2=80=99s why I = think puzzles should stay.

Yoav
= --Apple-Mail=_9A68E53C-DA9E-47F3-9B5E-B4973070B925-- From nobody Wed Nov 26 08:46:13 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DDD1A047A for ; Wed, 26 Nov 2014 08:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZTIB7aJ-lQ1 for ; Wed, 26 Nov 2014 08:46:09 -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 BC5731A0461 for ; Wed, 26 Nov 2014 08:46:06 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5A5622002A; Wed, 26 Nov 2014 11:49:01 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 57C57637F5; Wed, 26 Nov 2014 11:46:05 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3C68F637EA; Wed, 26 Nov 2014 11:46:05 -0500 (EST) From: Michael Richardson To: Yoav Nir In-Reply-To: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/lJI251V2--S_nRsg1dVr8WS7ilA Cc: ipsec Subject: Re: [IPsec] DDoS Protection issue #226 - Do we need puzzles at all? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 16:46:11 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > I don=E2=80=99t like hard limits. Hard limits allow a very easy form = of DoS. If > everyone in this hotel is behind a single NAT device, then it=E2=80= =99s fairly > easy for me to create multiple half-open SAs from my room until I hit > the hard limit. After that, everyone will be effectively blocked from Except now apply CGN in a IPv4-address poor country, and it's not just the people in the hotel, it's potentially everyone in that area. Given 300-odd well distributed, compromised hosts, one could keep the half-SA table full for much of the developing world... So I buy your argument. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVHYDyoCLcPvd0N1lAQJUcAf9E5DhRsADiOSBYouS7t4pyz2a9Q4AIWMa QSdRAccslrK/blsb7lAJ0B8aZj4vj39qXqyLxflGnqRM8y7LOWfWm1TkZStbwrrQ MnOnKlvkG4Da3JUX15os0F/fG73pJS4/rr9tmO3MQdvxOeA/vl3VySUQhHfgmK5v NeNyqGCp4HWCvkp6bzs2BLXLYMFGvqpWJJbP45KbmJbUacrlcuVJYMCUfPWSeao0 NeS3wRxGrKFnxAN7b/GDghs6DsoQoliI9sZfkLs3zvPMJfm5jtQQc0HS34Krs0pA iYR0NGBYwgvmv/DKUGOGtw0jlBBrrbXQfFfEt+/RT5GOnfYYZEISCA== =dfFn -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 26 11:05:41 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D462B1A1B47 for ; Wed, 26 Nov 2014 11:05:39 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8o5SXoJa14x for ; Wed, 26 Nov 2014 11:05:38 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A571A1B32 for ; Wed, 26 Nov 2014 11:05:38 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id l18so4494586wgh.26 for ; Wed, 26 Nov 2014 11:05:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=mVoxbb9w6w5OjVhgOu/WHP2gCaOsLtRsg8VBPS2xJRc=; b=HtSNV0CaqiF5LDIzcoMJRUmdDOKUlkKGiTQFxBNF2rtqv07vVznqkDEkwFz0bj/LuC FuInZW1eZknJVaRSLN76/u79QkHAWUu0Hhv4TejkUl99VZpb8PGwSbFmrRc52y+vQHis 7O3JPL3zERgabSXncp4SF8ri39i39y0weOMREYl88X+yFfpDiCrXKOXA2Mo+HmoyCSBM 1bNwrJtjW0x/oiSkOzyExZlZQ36RrScXBGS9W/HWsast/cDfuleIRwC4Wp5mGOkam/qS idZ888GihvEzwRR7USGsPOyago0LbjGmyq0sLf3AVvFOun3U02SZWljnf4vzshSGVEP0 5BPw== X-Received: by 10.180.85.6 with SMTP id d6mr44853600wiz.82.1417028736687; Wed, 26 Nov 2014 11:05:36 -0800 (PST) Received: from [10.0.0.9] (bzq-79-176-33-71.red.bezeqint.net. [79.176.33.71]) by mx.google.com with ESMTPSA id rx8sm7503797wjb.30.2014.11.26.11.05.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Nov 2014 11:05:36 -0800 (PST) Message-ID: <5476247F.4080609@gmail.com> Date: Wed, 26 Nov 2014 21:05:35 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Michael Richardson , Yoav Nir References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <15377.1417020365@sandelman.ca> In-Reply-To: <15377.1417020365@sandelman.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/bMPzEcYc8CZndVC4BAUOEYZD49U Cc: ipsec Subject: Re: [IPsec] DDoS Protection issue #226 - Do we need puzzles at all? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 19:05:40 -0000 I don't buy Yoav's argument but I also think puzzles should stay. The reason is, puzzles work well in the case where a botnet is attacking multiple gateways concurrently. Each gateway can rate-limit the traffic directed to it, but unless we associate a significant cost with each message, the botnet is as effective against each of the gateways as it would be if it was only attacking a single gateway. With puzzles, the "good guys" are helping one another without needing to communicate between them. Thanks, Yaron On 11/26/2014 06:46 PM, Michael Richardson wrote: > > Yoav Nir wrote: > > I don’t like hard limits. Hard limits allow a very easy form of DoS. If > > everyone in this hotel is behind a single NAT device, then it’s fairly > > easy for me to create multiple half-open SAs from my room until I hit > > the hard limit. After that, everyone will be effectively blocked from > > Except now apply CGN in a IPv4-address poor country, and it's not just the > people in the hotel, it's potentially everyone in that area. Given 300-odd > well distributed, compromised hosts, one could keep the half-SA table full > for much of the developing world... > > So I buy your argument. > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Wed Nov 26 12:02:16 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF61B1A1B35 for ; Wed, 26 Nov 2014 12:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.333 X-Spam-Level: X-Spam-Status: No, score=0.333 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UFoIrwEVemh for ; Wed, 26 Nov 2014 12:02:09 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE131A1B32 for ; Wed, 26 Nov 2014 12:02:09 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 371E635005B; Wed, 26 Nov 2014 12:02:09 -0800 (PST) Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPA id D9382350072; Wed, 26 Nov 2014 12:02:08 -0800 (PST) Date: Wed, 26 Nov 2014 14:02:08 -0600 From: Nico Williams To: Yoav Nir Message-ID: <20141126200205.GB3200@localhost> References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/_SOPeGY1BBZlYcBqYBM2-Ya1F7w Cc: ipsec Subject: Re: [IPsec] DDoS Protection issue #226 - Do we need puzzles at all? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 20:02:15 -0000 On Wed, Nov 26, 2014 at 02:01:22PM +0200, Yoav Nir wrote: > Puzzles limit the rate at which a particular host can create half-open > SAs. If the puzzle takes 2 seconds to solve then a particular > initiator (whether legitimate initiator, or a node in a bot-net) can > create at most 1 half-open SA every 2 seconds. > > Another way to achieve the same goal is to limit the half-open SA > lifetime to 10 seconds and have a hard limit of 5 concurrent half-open > SAs per peer. Sure, the attacker will be able to open 5 half-open SAs > within one second, but will then be rejected for the next 9. > > So why do I think we still need puzzles? I agree with your and Michael's points, but do recall that initiator/responder roles are exchangeable, and even when initiators are "clients" they might have to speak to many other responders. Puzzles/ puzzle complexity, seems like a good device for throttling half-open IKE SA creation when under load, but it might not be a good idea to have 2s puzzles on all the time. Nico -- From nobody Wed Nov 26 12:05:30 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD081A1B5C for ; Wed, 26 Nov 2014 12:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGw_4_MWpBaK for ; Wed, 26 Nov 2014 12:05:19 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA1E1A1B5F for ; Wed, 26 Nov 2014 12:05:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8070; q=dns/txt; s=iport; t=1417032318; x=1418241918; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ioxY1qwLD6sFO3eculyz+fWNHZfkuriyASlWlC4x6rc=; b=LcH7BHfXvrA+35vO9kxYVyLY2etgogsuIn6+sfYGRFxsiLC6+6X1T/VZ MYe/LQtewZxk+IpjGqTjLCN11WcUT+ZrR8n+Nc5f7eIG6ufWqcvm1wQfy d0cq7LT7HGFwT4YBOp4i5VCd3eip2rfCLQFfXRogHEZB6h/g0SvFFlcZC o=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAA8xdlStJV2T/2dsb2JhbABbgmMjUlcExWOCLQqGTQKBEBYBAQEBAX2EAwEBBAEBAWsbAgEIRgIlCyUCBAESDogyAQzSWwEBAQEBAQEBAgEBAQEBARyQJzkihE0FkmWCJ4FVa4c1gTU/gxqOBIQKggoYgVp3gUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.07,464,1413244800"; d="p7s'?scan'208";a="100411697" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP; 26 Nov 2014 20:05:15 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sAQK5F74004983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Nov 2014 20:05:15 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 14:05:14 -0600 From: "Graham Bartlett (grbartle)" To: "ipsec@ietf.org" , Yoav Nir Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-00.txt Thread-Index: AQHP8i/ndE20tkR+3keWIkzyL6SKVZxz6MaA Date: Wed, 26 Nov 2014 20:05:13 +0000 Message-ID: References: <20141027214823.13103.25135.idtracker@ietfa.amsl.com> In-Reply-To: <20141027214823.13103.25135.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.61.172.23] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3499877111_1249268" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/LMV3dB7Wevx7fgHKhsXAOef9YRA Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 20:05:28 -0000 --B_3499877111_1249268 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Yoav Here's some words I penned regarding some ideas I had to compliment your RFC. cheers RFC5685 describes the use of IKEv2 redirect to a client to another VPN gateway. For large scale implementations this can be used to redirect a client to a geographically closer gateway, thereby group clients by location. Eg. A client in London will initially request a session to vpn.example.com, based on the clients source IP address they are redirected to the European VPN gateway (eu.vpn.example.com), which only serves clients from Europe and prevents any non-European IP addresses connecting. Using this method geographically grouped IP addresses can be grouped to gateways, therefore preventing attackers not in the geographic group from connecting. This obviously doesn't prevent attackers from spoofing an IP address which would be accepted by the gateway. By limiting clients by location, IP TTL security mechanisms can be employed to accept certain connections from hosts a small number of hops away, therefore assisting to mitigate an attack from hosts distributed over the globe. On 27/10/2014 21:48, "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 >Working Group of the IETF. > > Title : Protecting Internet Key Exchange (IKE) >Implementations from Distributed Denial of Service Attacks > Author : Yoav Nir > Filename : draft-ietf-ipsecme-ddos-protection-00.txt > Pages : 12 > Date : 2014-10-27 > >Abstract: > This document recommends implementation and configuration best > practices for Internet-connected IPsec Responders, to allow them to > resist Denial of Service and Distributed Denial of Service attacks. > Additionally, the document introduces a new mechanism called "Client > Puzzles" that help accomplish this task. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-00 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec --B_3499877111_1249268 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIOeAYJKoZIhvcNAQcCoIIOaTCCDmUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggw+MIIEpzCCA4+gAwIBAgIQZmBP5MZi1b5ckUheWh5wbTANBgkqhkiG9w0BAQUFADBU MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv YmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMB4XDTE0MDEyNTIyNDE0OFoXDTE2MDYw MzExMDA1OFowQDEbMBkGA1UEAwwSZ3JiYXJ0bGVAY2lzY28uY29tMSEwHwYJKoZIhvcNAQkB FhJncmJhcnRsZUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCq YhYxolKrFoPfXuZTQdAiQVFg14EvWwIEMyXxhfH2RiwOSJRSsUVmTNYG8HdeSf0JdzjAMh9p ODgxLC90Q1nbLyBqmEAKElWTasAnATKBCD7aLhce+25cznTT4FDpJsvvU2lZFPWXSLQm3bNR +mEDP6pd8zR1ItOKBlNmGtwypUUvi4KrKRPzx1cSgVTN0Xocj4fC5N8Rj3tOqOns+EHOX4Rw oy/rebHjQyv1cRr6FyGhRuz24hPv8mAGr/iF0cMphAsujaGKyAo+tA05K3nI0fdoeCx2wdEs vo8jIeeZVii07b3K9+VdJQmerVKJyMfQT6gLkyuassY/5aXlglNxAgMBAAGjggGHMIIBgzAO BgNVHQ8BAf8EBAMCBaAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYm aHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wHQYDVR0RBBYwFIESZ3Ji YXJ0bGVAY2lzY28uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3Nw ZXJzb25hbHNpZ24xZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDov L3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24xZzIuY3J0MB0G A1UdDgQWBBRBHvZ1Aur9AFGMEId10iH6yeUX3jAfBgNVHSMEGDAWgBTsrJjMJ3KTz1YyzSPH nY1FhfQiAzANBgkqhkiG9w0BAQUFAAOCAQEAdhq5YZv5ZCu0/HdQF1S3f+quesVc39HKv+Fe 2rmKuJcxfGOFZGpKhJDa1+sFeN/T+e2e6UJ0Yy90GLqi5U1fioD3XRhsFiVOh7CbJQESF2Xx U1bhdutZFh6Ythe28iRPY6HQjJ/7ke5IQBWvLnAbCIzgy0GgZB9Vj+a2z6bzmfR6KAuLaMqM vahvJ0w+DeHMEOVnVzCdZzHMaEOXZHw/uZj5/hGvkp2C0rH/LhGunfAPX12WhVQSsgxWJhaF 8D49Ymrt7PWBsLokx06/15XwY2ogBmfLmeN/WhMy5HUiLn3EnzwF+RK2MStCDpP5AWzdnrTR tM43+AJrHwoI7H+C9DCCBBYwggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUA MFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdS b290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcN MTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1z YTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGjx0+LH0uRqeZCHrYQ7KN3QuahfxY8 fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqDlin3HracDqMRgwrknWuFeqxh N2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQBhcaJA2ucABbUVTHDTxi 7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+OhtnAhrgzrsd4oAy qgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7upoxvV09Fsf7h DeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUdIAAw NDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAf BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7un yEtmt9Ia7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDu vg/OZ0gILDFIa9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVU m5V1tW3XuYNg6SbtcDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVg wb/j/kplOa13nshhc8zULVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5ui B8TZ0s327g44Ylc6dgKgYelNn9RLYjNETX8OIJZlr0tFYpcYrDCCA3UwggJdoAMCAQICCwQA AAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJv b3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7m mY3Oo+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsur HExwB6E9CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8G PIhpWypNxadUuGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounI Cjjr8iQTT3NUkxOFOhu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjI GSvRRqpI1mQq14M0/ywqwWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8 /UswDQYJKoZIhvcNAQEFBQADggEBANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16q EUi25Qijs8o9YU3TRgmzPsOg42NVG/K676054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeY BN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8suWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUM HaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRWMZXQZ4mFK/lspl1GnQyqguSZUd1wt9tW PWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY24GzBBzFH6SAbxUgyd4MiAod1mZV 4vxIySkmaeAxggH+MIIB+gIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzIC EGZgT+TGYtW+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgOZ+G Wz0+klXj8qQSIddIhYeibIQ3Tq+MNcItAo9aIAwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTQxMTI2MjAwNTExWjANBgkqhkiG9w0BAQEFAASCAQBMjRgh Yxf34jZNc7N06jSCtHvcJRRZFLuPiuN9hvTTjwQwf0woPXCd8wmbDeZ17CTSQDpMw5qqsDAt hfVCfkX3gOEZkJpOxZuiwKNsNKFOBugJqtRW7ZIartReGXLrbiHWUamNiJztUE9qeXC1vymN Q+m07q6MB/sqfHSml1QwD9Me6duAuH18o/GrLdhi5VYlzWpPYi/9azACFMetKDbQNUEN2kUe 4hpUcK1AOQoTO2W205fFm5Db+PAy8B2h77MJaqX5mFQ8KGJ71wupEZSw07fOLepzZfFQYwS9 rqI0HxCeMrjmA+ReGNnCG7tQGSu1kHTeH+uqo7qY5JRAOifk --B_3499877111_1249268-- From nobody Wed Nov 26 12:10:44 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB121A1B56 for ; Wed, 26 Nov 2014 12:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oc1UOielTz0L for ; Wed, 26 Nov 2014 12:10:39 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9545C1A1B4A for ; Wed, 26 Nov 2014 12:10:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7008; q=dns/txt; s=iport; t=1417032639; x=1418242239; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8Y06Hs5ou5xAM8Qn5XFYYR5aKKLxDzxIgwuB+z19bjY=; b=m3nABTqVsWHuaHGvzihmEFLPoGo1pZSSZPQV285hl+kLr+4gJmIxStKy Zlq8AIrr3w444SjQ17CwTu5SdXUjcmCfY6QLBU+dWz++S6dludzyNN6UQ mjigfwl+mGX/rRaA7b78+vOyvokSsucgcAyuobSKl/z2pjSdj2hxjTwKa I=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFALQydlStJV2U/2dsb2JhbABbgmMjUlcExWOCLQqGTQKBEBYBAQEBAX2EAwEBBAEBAWsLEAIBCBguAiULJQIEAQ0FDogyAQzSXgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkCQ8GweETQWSZYIngVWIIIE1kV2ECoN8d4EHQYECAQEB X-IronPort-AV: E=Sophos;i="5.07,464,1413244800"; d="p7s'?scan'208";a="375624898" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP; 26 Nov 2014 20:10:36 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sAQKAaaE008114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Nov 2014 20:10:36 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 14:10:36 -0600 From: "Graham Bartlett (grbartle)" To: Nico Williams , Yoav Nir Thread-Topic: [IPsec] DDoS Protection issue #226 - Do we need puzzles at all? Thread-Index: AQHQCXC/9wWrlNTge06t8Tuvx6K8aJxzuWoAgAACWQA= Date: Wed, 26 Nov 2014 20:10:35 +0000 Message-ID: References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <20141126200205.GB3200@localhost> In-Reply-To: <20141126200205.GB3200@localhost> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.61.172.23] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3499877432_1282202" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ATP-I1JhXl8VSQi3xFUG0UmGhmc Cc: ipsec Subject: Re: [IPsec] DDoS Protection issue #226 - Do we need puzzles at all? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 20:10:42 -0000 --B_3499877432_1282202 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Great point. Puzzles a good tool that will be needed if/when ddos becomes a serious issue. (I can't think of a silver bullet which will solve this) They should also not be mandatory (with the option to be configurable as per cookie notifications) as I would assume some hosts will never be able to support these.. cheers On 26/11/2014 20:02, "Nico Williams" wrote: >On Wed, Nov 26, 2014 at 02:01:22PM +0200, Yoav Nir wrote: >> Puzzles limit the rate at which a particular host can create half-open >> SAs. If the puzzle takes 2 seconds to solve then a particular >> initiator (whether legitimate initiator, or a node in a bot-net) can >> create at most 1 half-open SA every 2 seconds. >> >> Another way to achieve the same goal is to limit the half-open SA >> lifetime to 10 seconds and have a hard limit of 5 concurrent half-open >> SAs per peer. Sure, the attacker will be able to open 5 half-open SAs >> within one second, but will then be rejected for the next 9. >> >> So why do I think we still need puzzles? > >I agree with your and Michael's points, but do recall that >initiator/responder roles are exchangeable, and even when initiators are >"clients" they might have to speak to many other responders. Puzzles/ >puzzle complexity, seems like a good device for throttling half-open IKE >SA creation when under load, but it might not be a good idea to have 2s >puzzles on all the time. > >Nico >-- > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec --B_3499877432_1282202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIOeAYJKoZIhvcNAQcCoIIOaTCCDmUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggw+MIIEpzCCA4+gAwIBAgIQZmBP5MZi1b5ckUheWh5wbTANBgkqhkiG9w0BAQUFADBU MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv YmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMB4XDTE0MDEyNTIyNDE0OFoXDTE2MDYw MzExMDA1OFowQDEbMBkGA1UEAwwSZ3JiYXJ0bGVAY2lzY28uY29tMSEwHwYJKoZIhvcNAQkB FhJncmJhcnRsZUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCq YhYxolKrFoPfXuZTQdAiQVFg14EvWwIEMyXxhfH2RiwOSJRSsUVmTNYG8HdeSf0JdzjAMh9p ODgxLC90Q1nbLyBqmEAKElWTasAnATKBCD7aLhce+25cznTT4FDpJsvvU2lZFPWXSLQm3bNR +mEDP6pd8zR1ItOKBlNmGtwypUUvi4KrKRPzx1cSgVTN0Xocj4fC5N8Rj3tOqOns+EHOX4Rw oy/rebHjQyv1cRr6FyGhRuz24hPv8mAGr/iF0cMphAsujaGKyAo+tA05K3nI0fdoeCx2wdEs vo8jIeeZVii07b3K9+VdJQmerVKJyMfQT6gLkyuassY/5aXlglNxAgMBAAGjggGHMIIBgzAO BgNVHQ8BAf8EBAMCBaAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYm aHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wHQYDVR0RBBYwFIESZ3Ji YXJ0bGVAY2lzY28uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3Nw ZXJzb25hbHNpZ24xZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDov L3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24xZzIuY3J0MB0G A1UdDgQWBBRBHvZ1Aur9AFGMEId10iH6yeUX3jAfBgNVHSMEGDAWgBTsrJjMJ3KTz1YyzSPH nY1FhfQiAzANBgkqhkiG9w0BAQUFAAOCAQEAdhq5YZv5ZCu0/HdQF1S3f+quesVc39HKv+Fe 2rmKuJcxfGOFZGpKhJDa1+sFeN/T+e2e6UJ0Yy90GLqi5U1fioD3XRhsFiVOh7CbJQESF2Xx U1bhdutZFh6Ythe28iRPY6HQjJ/7ke5IQBWvLnAbCIzgy0GgZB9Vj+a2z6bzmfR6KAuLaMqM vahvJ0w+DeHMEOVnVzCdZzHMaEOXZHw/uZj5/hGvkp2C0rH/LhGunfAPX12WhVQSsgxWJhaF 8D49Ymrt7PWBsLokx06/15XwY2ogBmfLmeN/WhMy5HUiLn3EnzwF+RK2MStCDpP5AWzdnrTR tM43+AJrHwoI7H+C9DCCBBYwggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUA MFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdS b290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcN MTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1z YTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGjx0+LH0uRqeZCHrYQ7KN3QuahfxY8 fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqDlin3HracDqMRgwrknWuFeqxh N2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQBhcaJA2ucABbUVTHDTxi 7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+OhtnAhrgzrsd4oAy qgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7upoxvV09Fsf7h DeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUdIAAw NDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAf BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7un yEtmt9Ia7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDu vg/OZ0gILDFIa9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVU m5V1tW3XuYNg6SbtcDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVg wb/j/kplOa13nshhc8zULVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5ui B8TZ0s327g44Ylc6dgKgYelNn9RLYjNETX8OIJZlr0tFYpcYrDCCA3UwggJdoAMCAQICCwQA AAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJv b3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7m mY3Oo+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsur HExwB6E9CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8G PIhpWypNxadUuGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounI Cjjr8iQTT3NUkxOFOhu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjI GSvRRqpI1mQq14M0/ywqwWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8 /UswDQYJKoZIhvcNAQEFBQADggEBANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16q EUi25Qijs8o9YU3TRgmzPsOg42NVG/K676054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeY BN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8suWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUM HaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRWMZXQZ4mFK/lspl1GnQyqguSZUd1wt9tW PWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY24GzBBzFH6SAbxUgyd4MiAod1mZV 4vxIySkmaeAxggH+MIIB+gIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzIC EGZgT+TGYtW+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgXGnW EoBDRv6UJ1QGKHapSFdLCGzzdYI/GgLWDGtKeF8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTQxMTI2MjAxMDMyWjANBgkqhkiG9w0BAQEFAASCAQA4fvLr KNPDLLB+naAE5o3JnpqR5oA/W1fQQKtK5l61B79j6g9fkPA5WzhF/XVulda2KiSc6YrlyDXn zbKaQPoSmrKAxg+Yy8SMCihnUpzSTMWPOJXNzyRhqTj5JSRH/JNe85JI47/z6FxK/oe3MteN BS1szOM0BeTwoFnKKlAasOmZsSTQDhSKyM38wTjggChnShNe8yXu90k9A85S4VyVbkZojWrf R52sG2hhBvW8UXxNrzHNiOhEDrdgoI3A4F2mGlUB5HllYgJMuy2CvBK9qUpj24EnuD6BmOob 6xINtCCdb6cKJJIbcgoXjfcc64o12lPMHsQ816oXGbrbgZhv --B_3499877432_1282202-- From nobody Wed Nov 26 14:17:40 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B8C1A6F81 for ; Wed, 26 Nov 2014 14:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LwFxs4BnLjb for ; Wed, 26 Nov 2014 14:17:22 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 326951A6F7F for ; Wed, 26 Nov 2014 14:17:22 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id B309A508072; Wed, 26 Nov 2014 14:17:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=SpGsNwG2E+XpEn 6TXn6zcPFchng=; b=C9pj1tD6fav6N3XnI7Ze5aQq78zPC9i8VbvTn/GMN1qMEw dXK8E0HjjU1uxfH4aa7HduwjuWL77kiNfYndLOJvHCPSUIUwzCzMPNf2I8TbcHmb QXKmyAEPd/8bflfUGw9abNwuROf7lOSwlO5fO8IFPGbafY0HYoXoi60fcY9+E= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPA id 27B12508063; Wed, 26 Nov 2014 14:17:21 -0800 (PST) Date: Wed, 26 Nov 2014 16:17:20 -0600 From: Nico Williams To: "Graham Bartlett (grbartle)" Message-ID: <20141126221547.GC3200@localhost> References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <20141126200205.GB3200@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/0IkKLchr0OriE2F88B2-lqlL5_4 Cc: ipsec , Yoav Nir Subject: Re: [IPsec] DDoS Protection issue #226 - Do we need puzzles at all? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 22:17:23 -0000 On Wed, Nov 26, 2014 at 08:10:35PM +0000, Graham Bartlett (grbartle) wrote: > Great point. Puzzles a good tool that will be needed if/when ddos becomes > a serious issue. (I can't think of a silver bullet which will solve this) For VPN SGs using puzzles all the time would be fine, but for VPN clients it'd be very rude to use them when acting as the responder! The protocol may be symmetric, but some uses aren't. VPN clients probably don't talk to more than one SG at a time, so why should they need puzzles at all? For single-user VPN clients there's not much of a DDoS problem. Even for BITW uses... For end-to-end IPsec using complex puzzles all the time would probably not be useful at all, but using them as load goes up would be very appropriate. Responder load seems like a variable that always works for deciding when to use puzzles and how complex they should be. VPN clients generally will never have too much IKE load, while SGs make tempting DDoS targets, therefore SGs could definitely use puzzles when under attack. Another variable worth using for determining puzzle complexity is the responder's estimated cost of holding the half-open IK_SA and completing the exchange. For a protocol where the initiator can demonstrate having recently been a productive peer there may be no need to make the initiator spend a lot of time on puzzles -- no need to punish the innocent parties, when you know who they are (but innocence is difficult to determine). > They should also not be mandatory (with the option to be configurable as > per cookie notifications) as I would assume some hosts will never be able > to support these.. Yes, but I'd rather we have a general recommendation with as simple a configuration knob as possible and with a sensible default setting that most will never need to change. IKE load seems like the most sensible variable to use in deciding when to use puzzles and how hard they should be. Specify the feature (puzzles) and provide general guidance as to when to use it and how hard to make it on the initiator. Nico -- From nobody Thu Nov 27 04:57:06 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203341A88F3 for ; Thu, 27 Nov 2014 04:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.338 X-Spam-Level: X-Spam-Status: No, score=0.338 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFJyMBGjl8mb for ; Thu, 27 Nov 2014 04:57:04 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6CE1A88F2 for ; Thu, 27 Nov 2014 04:57:03 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id n15so4164538lbi.16 for ; Thu, 27 Nov 2014 04:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=YXaT/3Trd33p+3H4kSq2EaOU1KIAzeNiW1OxDxraXzI=; b=ulbdP8E7QlzjsSU5bXPp1vj2YP84i6QNqb5YpO3Xhw930P6curqYSMBxbSUGrwXvOP sOwA0aAOAuwhzx8mX9Mlgz/EMKLgwLdOUEClAOPGGOWFp8it6KoJcEADS6Our2uZd9Mu miW3HAVaadb0Zyf+HZThLk3DSEJv0xdtlMol4nZJOSx6gcI9eUWwY8iyrpsMMsqfr5yV NpDT9T27yAh7B+9GsMnjCduMBraOXdXevEbr7dkFKRW3Obhd8I1zBqXdCggEWHWBd5gi ngxZEiJ94QctTtXzjYVefyCrAd3BBt4rAs4HB970bGKvr7OGjIrB7lqcB7EEjTh4EfRB FUAw== X-Received: by 10.112.167.200 with SMTP id zq8mr38969170lbb.61.1417093022068; Thu, 27 Nov 2014 04:57:02 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id k7sm1866584lak.22.2014.11.27.04.57.01 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 27 Nov 2014 04:57:01 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Paul Hoffman" , "IPsecME WG" References: Date: Thu, 27 Nov 2014 15:56:58 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/3zMXew8EUZ_NNFnWf64zgZLJkNE Subject: Re: [IPsec] Survey for WG interest in adoptingdraft-mglt-ipsecme-clone-ike-sa X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 12:57:05 -0000 Hi all, as a co-author of the draft I (obviously) support its adoption. I think that the mechanism it describes is useful and could be used as a building block for several solutions. For example, it can be used in load-sharing scenario when there are some gateways with different IP addresses, that share the same credentials. If client established IKE SA with any of them then the SA could be cloned and transfered to other nodes of this cluster without reauthentication, and the traffic from client then could be balanced among those gateways. Regards, Valery Smyslov. ----- Original Message ----- From: "Paul Hoffman" To: "IPsecME WG" Sent: Tuesday, November 25, 2014 11:06 PM Subject: [IPsec] Survey for WG interest in adoptingdraft-mglt-ipsecme-clone-ike-sa > > > Greetings again. The "Clone IKE SA" proposal tries to optimize IKE SA > setup in cases where VPN gateways have multiple interfaces and want to > establish different SAs on the different interfaces without having to > repeat the IKE authentication. Instead, they could clone a single IKE SA > multiple times, and then move it to different interfaces using MOBIKE. > > If you agree with the need to standardize this usage, and believe that > draft-mglt-ipsecme-clone-ike-sa is likely to be a good starting place for > that standardization, and are willing to review and contribute text to the > document if it is adopted by the WG, please say so on the list. This WG > has a history of adopting documents but then not having enough reviewers > for us to feel confident that we are making a good standard, so we need to > see a reasonable number of actively interested people before we adopt the > document. If it is not adopted, the authors can ask for it to be published > as an RFC through individual submission or by the Independent Submissions > Editor. > > Please reply by December 8, 2015. > > --Paul Hoffman and Yaron Sheffer > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Nov 27 05:00:33 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACEE1A88F7 for ; Thu, 27 Nov 2014 05:00:29 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLWL3E1Bbtpz for ; Thu, 27 Nov 2014 05:00:19 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AADEE1A88F3 for ; Thu, 27 Nov 2014 05:00:18 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id k14so6342539wgh.23 for ; Thu, 27 Nov 2014 05:00:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=pVDDwV1mLvGfbfMdi2o+iM8yTb4gbirNJ4xnEdCDlDQ=; b=wlrz80JQ3rKKaLYxMNMSU9TPJopxcX2kuGKEA3EO/ycZXISwhCxybnY/qWj3FSXKP5 olj9K/lNpDynLhfJ0wv9xsYPlwa0M7bErGgiJmLDMy0CaUD2z19EXfSIuAUi5vh/1T8B +tXycfJb5EzIW/Q8iCNB6YvYWpxaytCpTehDpWx9KUZIR5ARbCaR8ntRE7rO3VvYjkRX ptY6KX3JF/XGeMguuSatF6LpxGYZE1jfgeTa1EBwd46Q3exCAa9Y6KRYDbghcxDGBlaH 8G38J+utszhQ7JtMW/ulHVQadpKVIPFytrtod9s8WFRskIljIIoadoYHLrRNG+Qgo9B+ KjEw== X-Received: by 10.180.103.6 with SMTP id fs6mr34392494wib.11.1417093216814; Thu, 27 Nov 2014 05:00:16 -0800 (PST) Received: from [10.2.0.130] (93-172-142-150.bb.netvision.net.il. [93.172.142.150]) by mx.google.com with ESMTPSA id l3sm10629606wje.12.2014.11.27.05.00.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Nov 2014 05:00:16 -0800 (PST) Message-ID: <54772059.80805@gmail.com> Date: Thu, 27 Nov 2014 15:00:09 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Valery Smyslov , Paul Hoffman , IPsecME WG References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/rF9G8ufzSYzH7J0x1_yojOk_790 Subject: Re: [IPsec] Survey for WG interest in adoptingdraft-mglt-ipsecme-clone-ike-sa X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 13:00:31 -0000 Hi Valery, Have you looked at using session resumption (RFC 5723) for this, instead of coming up with a new mechanism? Thanks, Yaron On 11/27/2014 02:56 PM, Valery Smyslov wrote: > Hi all, > > as a co-author of the draft I (obviously) support its adoption. > > I think that the mechanism it describes is useful and could be used > as a building block for several solutions. For example, > it can be used in load-sharing scenario when there are > some gateways with different IP addresses, that share > the same credentials. If client established IKE SA with > any of them then the SA could be cloned and transfered > to other nodes of this cluster without reauthentication, > and the traffic from client then could be balanced > among those gateways. > > Regards, > Valery Smyslov. > > > ----- Original Message ----- From: "Paul Hoffman" > To: "IPsecME WG" > Sent: Tuesday, November 25, 2014 11:06 PM > Subject: [IPsec] Survey for WG interest in > adoptingdraft-mglt-ipsecme-clone-ike-sa > > >> >> >> Greetings again. The "Clone IKE SA" proposal tries to optimize IKE SA >> setup in cases where VPN gateways have multiple interfaces and want to >> establish different SAs on the different interfaces without having to >> repeat the IKE authentication. Instead, they could clone a single IKE >> SA multiple times, and then move it to different interfaces using MOBIKE. >> >> If you agree with the need to standardize this usage, and believe that >> draft-mglt-ipsecme-clone-ike-sa is likely to be a good starting place >> for that standardization, and are willing to review and contribute >> text to the document if it is adopted by the WG, please say so on the >> list. This WG has a history of adopting documents but then not having >> enough reviewers for us to feel confident that we are making a good >> standard, so we need to see a reasonable number of actively interested >> people before we adopt the document. If it is not adopted, the authors >> can ask for it to be published as an RFC through individual submission >> or by the Independent Submissions Editor. >> >> Please reply by December 8, 2015. >> >> --Paul Hoffman and Yaron Sheffer >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Nov 27 06:26:13 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EBE1A802C for ; Thu, 27 Nov 2014 06:26:12 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKGSqkE-HwBB for ; Thu, 27 Nov 2014 06:26:10 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931401A0111 for ; Thu, 27 Nov 2014 06:26:09 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id n15so4237553lbi.2 for ; Thu, 27 Nov 2014 06:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=8Iu2nxqGOket7x9Tj4060aFwKIL2QniLssqU60HdJDM=; b=0gTLHYXja8koGhAFBMGWBuuu5sDPpxHlaj2MdwxZ3Fg8kKft43pykJc6OBTCstfc5d E7nW4Im0FZVv3oGCNKD+C+5BomdnrcLH9IXQuP4rw6Limw6Gs+/ntqIVS03SikKvGO9i NWodnZ+mHB0JBUoaoAg/tiBAZwzaSFqR+Sh++ZTbwz1H1MQnEVqqK0A6WnxSBjQ8pXDQ utwy8bfgb2oIcVFeLD9sYMW2F7YAp6mHg4rNO0/QiKfM/yQwHcvk9QvbND/yG9T/bIIj ilOTzSuXFJtagEekCfKT4EwNzoI0HBYvQZGpxGUP3WqMEk+HvPYDDBKkY2RfmckQVo4X Qi7Q== X-Received: by 10.152.4.233 with SMTP id n9mr23729833lan.61.1417098368050; Thu, 27 Nov 2014 06:26:08 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id m3sm1914189laa.10.2014.11.27.06.26.06 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 27 Nov 2014 06:26:07 -0800 (PST) Message-ID: <73B67B471295424A839CDE89A4327503@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" , "Paul Hoffman" , "IPsecME WG" References: <54772059.80805@gmail.com> Date: Thu, 27 Nov 2014 17:26:04 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/X2zv9xi245h5DzEEDVZwsAAp3Zw Subject: Re: [IPsec] Survey for WG interest in adoptingdraft-mglt-ipsecme-clone-ike-sa X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 14:26:12 -0000 Hi Yaron, one disadvantage is that client in this case must know all the cluster's addresses beforehand. It is better when cluster itself makes decision when and where to move any particular client and client plays only passive role. And resumption tickets are intended to restore IKE SA with that particular gate, not to clone it. So tickets are one-time use. I think ticket management can become too complex if we want to allow client to have multiple tickets and to use them in any order with any of cluster member. Regards, Valery. ----- Original Message ----- From: "Yaron Sheffer" To: "Valery Smyslov" ; "Paul Hoffman" ; "IPsecME WG" Sent: Thursday, November 27, 2014 4:00 PM Subject: Re: [IPsec] Survey for WG interest in adoptingdraft-mglt-ipsecme-clone-ike-sa > > > Hi Valery, > > Have you looked at using session resumption (RFC 5723) for this, instead > of coming up with a new mechanism? > > Thanks, > Yaron > > On 11/27/2014 02:56 PM, Valery Smyslov wrote: >> Hi all, >> >> as a co-author of the draft I (obviously) support its adoption. >> >> I think that the mechanism it describes is useful and could be used >> as a building block for several solutions. For example, >> it can be used in load-sharing scenario when there are >> some gateways with different IP addresses, that share >> the same credentials. If client established IKE SA with >> any of them then the SA could be cloned and transfered >> to other nodes of this cluster without reauthentication, >> and the traffic from client then could be balanced >> among those gateways. >> >> Regards, >> Valery Smyslov. >> >> >> ----- Original Message ----- From: "Paul Hoffman" >> To: "IPsecME WG" >> Sent: Tuesday, November 25, 2014 11:06 PM >> Subject: [IPsec] Survey for WG interest in >> adoptingdraft-mglt-ipsecme-clone-ike-sa >> >> >>> >>> >>> Greetings again. The "Clone IKE SA" proposal tries to optimize IKE SA >>> setup in cases where VPN gateways have multiple interfaces and want to >>> establish different SAs on the different interfaces without having to >>> repeat the IKE authentication. Instead, they could clone a single IKE >>> SA multiple times, and then move it to different interfaces using >>> MOBIKE. >>> >>> If you agree with the need to standardize this usage, and believe that >>> draft-mglt-ipsecme-clone-ike-sa is likely to be a good starting place >>> for that standardization, and are willing to review and contribute >>> text to the document if it is adopted by the WG, please say so on the >>> list. This WG has a history of adopting documents but then not having >>> enough reviewers for us to feel confident that we are making a good >>> standard, so we need to see a reasonable number of actively interested >>> people before we adopt the document. If it is not adopted, the authors >>> can ask for it to be published as an RFC through individual submission >>> or by the Independent Submissions Editor. >>> >>> Please reply by December 8, 2015. >>> >>> --Paul Hoffman and Yaron Sheffer >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Nov 27 08:22:19 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AE51A00F5 for ; Thu, 27 Nov 2014 08:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJa2iSBpnWfD for ; Thu, 27 Nov 2014 08:22:14 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A83C1A00DE for ; Thu, 27 Nov 2014 08:22:14 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EA43F817C1; Thu, 27 Nov 2014 11:22:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1417105332; bh=hrwvSQSgQf1WiRgxey2B75DMGJF9EP1Z9PZEul2ymKM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MrSl/u4NaLxgFp3eV6JJh5KZw5LEjzjCcSa/EYpsdLJbMDllPhqxYbYQeoN4qg8Pe NyCwYSP8PUb9FojFrIUp39k7XFgE3APjlU6VbI1XvrroLPhpmm9fTneZ98xM79Q+SM 6zxGEGP8SysrV0vT+yunN15KpBMteTkmhmY789RA= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sARGMB8b009237; Thu, 27 Nov 2014 11:22:12 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 27 Nov 2014 11:22:11 -0500 (EST) From: =?UTF-8?Q?Paul_Wouters_=F0=9F=94=93?= To: Valery Smyslov In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/rIpecJA0i6ATKBq7oD_lJmyZ0ak Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] Survey for WG interest in adoptingdraft-mglt-ipsecme-clone-ike-sa X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 16:22:17 -0000 On Thu, 27 Nov 2014, Valery Smyslov wrote: > I think that the mechanism it describes is useful and could be used > as a building block for several solutions. For example, > it can be used in load-sharing scenario when there are > some gateways with different IP addresses, that share > the same credentials. If client established IKE SA with > any of them then the SA could be cloned and transfered > to other nodes of this cluster without reauthentication, > and the traffic from client then could be balanced > among those gateways. That would run into replay protection problems, just like if you copy all kernel IPsec state between machines. And I believe load sharing when properly done should be invisible to client side and not need special support. >> Greetings again. The "Clone IKE SA" proposal tries to optimize IKE SA setup >> in cases where VPN gateways have multiple interfaces and want to establish >> different SAs on the different interfaces without having to repeat the IKE >> authentication. Instead, they could clone a single IKE SA multiple times, >> and then move it to different interfaces using MOBIKE. >> >> If you agree with the need to standardize this usage, and believe that >> draft-mglt-ipsecme-clone-ike-sa is likely to be a good starting place for >> that standardization, and are willing to review and contribute text to the >> document if it is adopted by the WG, please say so on the list. I am interested in the problem, but have bad feelings about throwing around IKE states from two peers to another peer, which this mechanism seems to leave open. For instance, I would much rather see some informational exchange method or create child sa method using the existing IKE SA for conveying this information and somehow creatie the additional new Child SA. Throwing around private keys or computed shared secrets to multiple peers worry me. Paul From nobody Fri Nov 28 03:13:48 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F371A1B0E for ; Fri, 28 Nov 2014 03:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhL5E7gF5Qoi for ; Fri, 28 Nov 2014 03:13:44 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 CFA271A1B07 for ; Fri, 28 Nov 2014 03:13:43 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sASBDdSL016089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Nov 2014 13:13:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sASBDc4w005117; Fri, 28 Nov 2014 13:13:38 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21624.22754.429487.324323@fireball.kivinen.iki.fi> Date: Fri, 28 Nov 2014 13:13:38 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> References: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 5 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/HcbNQX8A2CLZxuPQfYNXhbdG8-c Cc: IPsecME WG Subject: [IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 11:13:46 -0000 Paul Hoffman writes: > If you agree with the need to standardize this usage, and believe > that draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good > starting place for that standardization, and are willing to review > and contribute text to the document if it is adopted by the WG, > please say so on the list. I think we should standardize this usage, and that draft might be good starting point (I do have quite a lot of comments to it, I will sent out shortly). > This WG has a history of adopting documents but then not having > enough reviewers for us to feel confident that we are making a good > standard, so we need to see a reasonable number of actively > interested people before we adopt the document. If it is not > adopted, the authors can ask for it to be published as an RFC > through individual submission or by the Independent Submissions > Editor. Either due through this working group or through individual submission would be fine. I do not like documenting extensions to the standard track protocol through independed submissions editor, especially if the idea is to make such extension standard used between multiple vendors. Some vendor just wanting to document their own way of doing something would be fine through ISE, but if I have understood correctly the reason this effor is ongoing is to make extension that can be used between multiple vendors. For such effort IETF stream would be better. -- kivinen@iki.fi From nobody Fri Nov 28 03:43:53 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E501A1B39 for ; Fri, 28 Nov 2014 03:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7DdZRtdXO2Q for ; Fri, 28 Nov 2014 03:43:50 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0E201A1B07 for ; Fri, 28 Nov 2014 03:43:49 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id pn19so4713314lab.23 for ; Fri, 28 Nov 2014 03:43:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=3r1IcK0ObK3jC53RYnM8GaOUCrvPZh1ZCU41AAmNWhU=; b=S0q4KO3HH3YRccL+Vb1lNdzwSScJ9gsoNdPBvGrsJGcQGP4Yixc9vNV/blgnORKdLO O729lwtw7bAJw0eTyoiKbPY0l0pnCTmhuV+VB7T4X5zZq/7EzMlOIhp9hGfsp/i6CBuI egCRjqzw256MTfsW8YSZ7Iu0hS9QwjXZ07nDAM77sKgvuxVT+B7lDSVVl97JVcjvA1Ho b64sHKFmPXgnzNJdrGaqCQ6me6Q6JZz7MGOecDBSV3DUl1Qtr6g4V39Ib8LVT++FZ9MB 11qiQDyeuiy4dKIjRt36hlrSkWu6kVVAKXlL5Qz6z32wspukuwOpir+ubVRnibvb5RHw qNHA== X-Received: by 10.152.6.166 with SMTP id c6mr43476562laa.20.1417175028503; Fri, 28 Nov 2014 03:43:48 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id f4sm2539542laa.9.2014.11.28.03.43.47 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 28 Nov 2014 03:43:47 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Paul Wouters ??" References: Date: Fri, 28 Nov 2014 14:43:52 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/n-LiZVzlJh4u6e4d9Nn2r5ERNQQ Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] Survey for WG interest in adoptingdraft-mglt-ipsecme-clone-ike-sa X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 11:43:52 -0000 Hi Paul, >> I think that the mechanism it describes is useful and could be used >> as a building block for several solutions. For example, >> it can be used in load-sharing scenario when there are >> some gateways with different IP addresses, that share >> the same credentials. If client established IKE SA with >> any of them then the SA could be cloned and transfered >> to other nodes of this cluster without reauthentication, >> and the traffic from client then could be balanced >> among those gateways. > > That would run into replay protection problems, just like if you copy > all kernel IPsec state between machines. Why? If I copy only IKE SA and then create IPsec SAs on new gateway there will be no need to copy kernel IPsec states and deal with replay protection. > And I believe load sharing > when properly done should be invisible to client side and not need > special support. I agree with you in general, but I don't think it is always feasible in case of IPsec without some cooperation with client (or you will really need to share kernel IPsec state between cluster nodes). >>> Greetings again. The "Clone IKE SA" proposal tries to optimize IKE SA >>> setup in cases where VPN gateways have multiple interfaces and want to >>> establish different SAs on the different interfaces without having to >>> repeat the IKE authentication. Instead, they could clone a single IKE SA >>> multiple times, and then move it to different interfaces using MOBIKE. >>> >>> If you agree with the need to standardize this usage, and believe that >>> draft-mglt-ipsecme-clone-ike-sa is likely to be a good starting place >>> for that standardization, and are willing to review and contribute text >>> to the document if it is adopted by the WG, please say so on the list. > > I am interested in the problem, but have bad feelings about throwing > around IKE states from two peers to another peer, which this > mechanism seems to leave open. For instance, I would much rather see > some informational exchange method or create child sa method using the > existing IKE SA for conveying this information and somehow creatie the > additional new Child SA. Isn't this similar to what resumption does? > Throwing around private keys or computed shared secrets to multiple > peers worry me. It is often unavoidable in case of clusters. And of course all due precautions need to be taken in this case to minimize chances to leak information. Valery. > Paul From nobody Fri Nov 28 05:14:28 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A83E1A1B5F for ; Fri, 28 Nov 2014 05:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CUvmKhD88Km for ; Fri, 28 Nov 2014 05:14:24 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 39B591A1B66 for ; Fri, 28 Nov 2014 05:14:24 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sASDEMxa003817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Nov 2014 15:14:22 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sASDEKlH000762; Fri, 28 Nov 2014 15:14:20 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21624.29996.851926.333259@fireball.kivinen.iki.fi> Date: Fri, 28 Nov 2014 15:14:20 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 1 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/3PVyrgfLTE2SqJX4WTTaWDVy8xs Cc: IPsecME WG Subject: [IPsec] Survey for WG interest in adopting draft-mglt-ipsecme-clone-ike-sa X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 13:14:25 -0000 Paul Hoffman writes: > Greetings again. The "Clone IKE SA" proposal tries to optimize IKE > SA setup in cases where VPN gateways have multiple interfaces and > want to establish different SAs on the different interfaces without > having to repeat the IKE authentication. Instead, they could clone a > single IKE SA multiple times, and then move it to different > interfaces using MOBIKE. > > If you agree with the need to standardize this usage, and believe > that draft-mglt-ipsecme-clone-ike-sa is likely to be a good starting > place for that standardization, and are willing to review and > contribute text to the document if it is adopted by the WG, please > say so on the list. I support adopting this document for WG draft, or just go forward as individual submission. I have already reviewed this draft, and I think it is mostly ready already, so we could even start WG or IETF last call almost immediately. -- kivinen@iki.fi From nobody Fri Nov 28 05:50:52 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402871A1A73 for ; Fri, 28 Nov 2014 05:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGNs43XWDOI3 for ; Fri, 28 Nov 2014 05:50:50 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 D08C41A1A6C for ; Fri, 28 Nov 2014 05:50:49 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sASDoikX012126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Nov 2014 15:50:44 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sASDohta003018; Fri, 28 Nov 2014 15:50:43 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21624.32179.838590.460413@fireball.kivinen.iki.fi> Date: Fri, 28 Nov 2014 15:50:43 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 24 min X-Total-Time: 12 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/fLrfBbTq4_Az2yE7bbhP2aeqBP4 Cc: IPsecME WG , Valery Smyslov Subject: Re: [IPsec] Survey for WG interest in adoptingdraft-mglt-ipsecme-clone-ike-sa X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 13:50:51 -0000 Paul Wouters writes: > On Thu, 27 Nov 2014, Valery Smyslov wrote: > > > I think that the mechanism it describes is useful and could be used > > as a building block for several solutions. For example, > > it can be used in load-sharing scenario when there are > > some gateways with different IP addresses, that share > > the same credentials. If client established IKE SA with > > any of them then the SA could be cloned and transfered > > to other nodes of this cluster without reauthentication, > > and the traffic from client then could be balanced > > among those gateways. > > That would run into replay protection problems, just like if you copy > all kernel IPsec state between machines. And I believe load sharing > when properly done should be invisible to client side and not need > special support. Actually I tihnk the idea is to get rid of the replay protection issues. In normal case if you just copy all IKE and IPsec state between the servers, then you need to make sure you also copy all replay data. If you clone the IKE SA, move the cloned IKE SA to new IP-address (and new load sharing server in the cluster), and then create the IPsec Child SAs there, then each of the replay data is only located in the server you are talking to, and there is no need to move replay data between the cluster members. If the load sharing is done so it is invisible to the client, then you always end up problems with the replay protection data. If it is done this way where the client is aware of the different cluster members then there is no problem with the replay protection data. > I am interested in the problem, but have bad feelings about throwing > around IKE states from two peers to another peer, which this > mechanism seems to leave open. No, this draft addresses just that problem, i.e. it WILL NOT throw away IKE states from peer to another. It will simply clone the current IKEv2 SA, so after the operation there are two completely independent IKEv2 SAs. Each of those IKEv2 SAs have their own replay windows, and counters, and both have their own independent set of Child SAs. The draft mentions tha twe already have MOBIKE which can be used to move the IKEv2 SA and all associated Child SAs from one IP to another, i.e. it can be used to transfer SA from one IP address to another, and if the second IP address is not actually in the same physical box, but happens to be IP address of the another member in the shared cluster, that is something that client cannot know. The cluster just then need to make sure that it transfers the another independed IKE SA to that other peer when doing mobike operation to change the IP address. > For instance, I would much rather see some informational exchange > method or create child sa method using the existing IKE SA for > conveying this information and somehow creatie the additional new > Child SA. I do not understand what you are meaning here. > Throwing around private keys or computed shared secrets to multiple > peers worry me. Private keys do not need to be transmitted, only the SKEYSEED and material generated from there needs to be transmitted (i.e. the computed shared state). Doing load-sharing without the client knowledge, do require exactly same material to be transmitted, but in addition to that all the replay protection related material needs to be transmitted also. -- kivinen@iki.fi From nobody Fri Nov 28 07:52:02 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5261A00A2 for ; Fri, 28 Nov 2014 07:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFyoS06vLOw7 for ; Fri, 28 Nov 2014 07:52:00 -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 3A23B1A00D6 for ; Fri, 28 Nov 2014 07:51:57 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3ECDC2009E for ; Fri, 28 Nov 2014 10:54:59 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 69ECF637F5; Fri, 28 Nov 2014 10:51:56 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5265B637EA for ; Fri, 28 Nov 2014 10:51:56 -0500 (EST) From: Michael Richardson To: IPsecME WG In-Reply-To: <21624.22754.429487.324323@fireball.kivinen.iki.fi> References: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> <21624.22754.429487.324323@fireball.kivinen.iki.fi> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/b9VW4IXb0LgEmC9jaK1aoDuCuiA Subject: Re: [IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 15:52:01 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: >> This WG has a history of adopting documents but then not having >> enough reviewers for us to feel confident that we are making a good >> standard, so we need to see a reasonable number of actively >> interested people before we adopt the document. If it is not >> adopted, the authors can ask for it to be published as an RFC >> through individual submission or by the Independent Submissions >> Editor. > Either due through this working group or through individual submission > would be fine. I do not like documenting extensions to the standard > track protocol through independed submissions editor, especially if > the idea is to make such extension standard used between multiple > vendors. Some vendor just wanting to document their own way of doing I believe that no matter how it proceeds, this extension will definitely ne= ed to be marked "experimental".=20=20 I think that there can be no-interoperation of the IKEv2 side without interoperation at the QKD side. My reading is that the QKD side requires=20 an unbroken light pipe connection between the two end-points (not sure if amplification is allowed; I suspect not).=20=20 I agree that really, it's out-of-scope to IPsecME to care about that: the t= wo end points just have some really high quality random bits that they "share", and really, *ANY* mechanism (including Pony Express) would do. {which rais= es the question: why KINK isn't a better place for them to start} As such, I don't see how this work can become "standard" for along time. Maybe the bis-bis of it. I am, however, all for accomodating the need for protocol numbers to make t= his work. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVHiaGYCLcPvd0N1lAQJhzwgAn4THmW37xjiE80AJUFiZkShJRH+pthpw oSnum1+kda2m0oIUSGHFyQfJgpWPOQg9GyZvwkteNmz0wJEf08cuYcc6eweZgamw EM88nFgnHAPY6GeOxW/Cv9CpEVq3LfyNfV9x2tXEj72FZIBuii2TqADm/FnkZ1xq X5RxTekjc1JbfUUJrwCI6W6BirkiwlUTIvOhjIRCPHh5lByRKLulFz1VmTOLSCyZ 2IamgQPXJYSpaUwcB1EGpDul9GAKcCkwr34VBG4I3ghDjNLd0UU0dQaqWLETz4V5 c3uvgMGs+0wdGJyX4NujHTqXAOh7ET5a6eDUyf0D6ZOuupQ8bDNXkA== =HLvR -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 28 11:21:43 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85701A00D7 for ; Fri, 28 Nov 2014 11:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eo-9lsxeb9xC for ; Fri, 28 Nov 2014 11:21:40 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 533F31A00C5 for ; Fri, 28 Nov 2014 11:21:40 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CF274817C1; Fri, 28 Nov 2014 14:21:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1417202498; bh=lVDVQfTl1J7wBuOtqaQ2oNvQUNTKbie3zkpulU1kwy0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=pNjR+sdyU9YiSFK7CuRGKqFW9v05T3iatoRFBvw4jSaeKdYCFmfEJyjS5Ili40r3K LljbJ0tlZMK7kO01cTWnHj2ETVKXaQeajIe9OFz+23w4i9QrCnSUb1jSWWNwEyscfr WSikDyw0QMhvxHoWund4PuYCpEzMV+2aiqplY6ZY= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sASJLcq2002664; Fri, 28 Nov 2014 14:21:38 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 28 Nov 2014 14:21:38 -0500 (EST) From: =?UTF-8?Q?Paul_Wouters_=F0=9F=94=93?= To: Paul Hoffman In-Reply-To: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> Message-ID: References: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/QAD5Vmzgy671KumJCv8DorBtiS8 Cc: IPsecME WG Subject: Re: [IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 19:21:41 -0000 On Tue, 25 Nov 2014, Paul Hoffman wrote: > Greetings again. There is a small emerging industry of crypto solutions that transmit keys using Quantum Key Distribution (QKD), and then use those keys for classical high-speed encryption. Several such solutions are using IKE, and there is a perceived need to standardize this usage. If so, that standardization should be done in this Working Group. > > If you agree with the need to standardize this usage, and believe that draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good starting place for that standardization, and are willing to review and contribute text to the document if it is adopted by the WG, please say so on the list. This WG has a history of adopting documents but then not having enough reviewers for us to feel confident that we are making a good standard, so we need to see a reasonable number of actively interested people before we adopt the document. If it is not adopted, the authors can ask for it to be published as an RFC through individual submission or by the Independent Submissions Editor. I'm in favor of adopting this document as I can see a real use for this in the future and since it is making changes to the IKE core protocol, it would be best that this group is involved in that discussion. Some comments after a quick read: Why is the fallback field/mode negotiation required? Typically, those decisions would be determined by local policy, and the remote end is informed of that local policy by a new incoming IKE request (or not) that uses a QKD payload or a DH payload. If the peers disagree about the fallback method, would that prevent initial establishment of IKE? Why not leave the DH in place and just ignore the SKEYSEED / prf and use the QKD bits for the private keys (or OTP)? It's less changes to the IKE protocol (and friendlier to implementers :) Having an OTP mode, even without QKD would actually be neat, although it would require a lot of kernel work too :) Paul From nobody Sun Nov 30 14:17:02 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5791A1A92 for ; Sun, 30 Nov 2014 14:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.111 X-Spam-Level: X-Spam-Status: No, score=-13.111 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWwDLcl8zrmD for ; Sun, 30 Nov 2014 14:16:58 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BD2C1A1A91 for ; Sun, 30 Nov 2014 14:16:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7006; q=dns/txt; s=iport; t=1417385818; x=1418595418; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RonOsfjgzYILETFZcUQhB8Ss/iQswJKnCkZM73SJcRA=; b=UicTlaWq+Stk3TnFltmoio3PsjyP1nyqHnal5sbtnMhFb/LmuUSnXQ1g hfJ75idJq+16kS3LPbfFjg8j0MRxGDXN5R0lyNM4FDdLMBsqaTlmWfna9 afq+9i8JmDPYPbfDQKa8a/3UHLEGhBn9lyjci0SuAuRopuAJF/L3/QHcj g=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFABeXe1StJA2K/2dsb2JhbABSCYJjI4EpBMRViHYCgQoWAQEBAQF9hAMBAQR5EAIBCEYCMCUCBA4FDogyAdFqAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5AgQBsHhEgBBJEFghiBTodclUOCChiBWW+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.07,489,1413244800"; d="p7s'?scan'208";a="101332921" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP; 30 Nov 2014 22:16:58 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sAUMGvDP000765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 30 Nov 2014 22:16:57 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Sun, 30 Nov 2014 16:16:57 -0600 From: "Graham Bartlett (grbartle)" To: Nico Williams Thread-Topic: [IPsec] DDoS Protection issue #226 - Do we need puzzles at all? Thread-Index: AQHQCXC/9wWrlNTge06t8Tuvx6K8aJxzuWoAgAACWQCAACNtAIAGSTiA Date: Sun, 30 Nov 2014 22:16:57 +0000 Message-ID: References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <20141126200205.GB3200@localhost> <20141126221547.GC3200@localhost> In-Reply-To: <20141126221547.GC3200@localhost> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.55.146.100] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3500230617_7874043" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/_BjYl2wYSRtf5OoQ_1AVy7cUdlw Cc: ipsec , Yoav Nir Subject: Re: [IPsec] DDoS Protection issue #226 - Do we need puzzles at all? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 22:17:01 -0000 --B_3500230617_7874043 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Nico On 26/11/2014 22:17, "Nico Williams" wrote: >For VPN SGs using puzzles all the time would be fine, but for VPN >clients it'd be very rude to use them when acting as the responder! The >protocol may be symmetric, but some uses aren't. > >VPN clients probably don't talk to more than one SG at a time, so why >should they need puzzles at all? For single-user VPN clients there's >not much of a DDoS problem. Even for BITW uses.. > >For end-to-end IPsec using complex puzzles all the time would probably >not be useful at all, but using them as load goes up would be very >appropriate. Is this for 2 peers with a site-site IPsec (with known addresses)? I agree that there would be little need for puzzles as security controls - IPS/Firewall (even Cookie Notifications) etc would be better suited to mitigating an attack as the peer address is known and would need to be spoofed. > >Another variable worth using for determining puzzle complexity is the >responder's estimated cost of holding the half-open IK_SA and completing >the exchange. For a protocol where the initiator can demonstrate having >recently been a productive peer there may be no need to make the >initiator spend a lot of time on puzzles -- no need to punish the >innocent parties, when you know who they are (but innocence is difficult >to determine). This is interesting, so maybe you could have a token that is bound to identity, if you have completed a puzzle it's valid for x period of time? This is presented to over-ride having to complete a puzzle? cheers --B_3500230617_7874043 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIOeAYJKoZIhvcNAQcCoIIOaTCCDmUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggw+MIIEpzCCA4+gAwIBAgIQZmBP5MZi1b5ckUheWh5wbTANBgkqhkiG9w0BAQUFADBU MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv YmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMB4XDTE0MDEyNTIyNDE0OFoXDTE2MDYw MzExMDA1OFowQDEbMBkGA1UEAwwSZ3JiYXJ0bGVAY2lzY28uY29tMSEwHwYJKoZIhvcNAQkB FhJncmJhcnRsZUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCq YhYxolKrFoPfXuZTQdAiQVFg14EvWwIEMyXxhfH2RiwOSJRSsUVmTNYG8HdeSf0JdzjAMh9p ODgxLC90Q1nbLyBqmEAKElWTasAnATKBCD7aLhce+25cznTT4FDpJsvvU2lZFPWXSLQm3bNR +mEDP6pd8zR1ItOKBlNmGtwypUUvi4KrKRPzx1cSgVTN0Xocj4fC5N8Rj3tOqOns+EHOX4Rw oy/rebHjQyv1cRr6FyGhRuz24hPv8mAGr/iF0cMphAsujaGKyAo+tA05K3nI0fdoeCx2wdEs vo8jIeeZVii07b3K9+VdJQmerVKJyMfQT6gLkyuassY/5aXlglNxAgMBAAGjggGHMIIBgzAO BgNVHQ8BAf8EBAMCBaAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYm aHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wHQYDVR0RBBYwFIESZ3Ji YXJ0bGVAY2lzY28uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3Nw ZXJzb25hbHNpZ24xZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDov L3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24xZzIuY3J0MB0G A1UdDgQWBBRBHvZ1Aur9AFGMEId10iH6yeUX3jAfBgNVHSMEGDAWgBTsrJjMJ3KTz1YyzSPH nY1FhfQiAzANBgkqhkiG9w0BAQUFAAOCAQEAdhq5YZv5ZCu0/HdQF1S3f+quesVc39HKv+Fe 2rmKuJcxfGOFZGpKhJDa1+sFeN/T+e2e6UJ0Yy90GLqi5U1fioD3XRhsFiVOh7CbJQESF2Xx U1bhdutZFh6Ythe28iRPY6HQjJ/7ke5IQBWvLnAbCIzgy0GgZB9Vj+a2z6bzmfR6KAuLaMqM vahvJ0w+DeHMEOVnVzCdZzHMaEOXZHw/uZj5/hGvkp2C0rH/LhGunfAPX12WhVQSsgxWJhaF 8D49Ymrt7PWBsLokx06/15XwY2ogBmfLmeN/WhMy5HUiLn3EnzwF+RK2MStCDpP5AWzdnrTR tM43+AJrHwoI7H+C9DCCBBYwggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUA MFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdS b290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcN MTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1z YTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGjx0+LH0uRqeZCHrYQ7KN3QuahfxY8 fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqDlin3HracDqMRgwrknWuFeqxh N2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQBhcaJA2ucABbUVTHDTxi 7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+OhtnAhrgzrsd4oAy qgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7upoxvV09Fsf7h DeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUdIAAw NDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAf BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7un yEtmt9Ia7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDu vg/OZ0gILDFIa9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVU m5V1tW3XuYNg6SbtcDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVg wb/j/kplOa13nshhc8zULVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5ui B8TZ0s327g44Ylc6dgKgYelNn9RLYjNETX8OIJZlr0tFYpcYrDCCA3UwggJdoAMCAQICCwQA AAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJv b3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7m mY3Oo+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsur HExwB6E9CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8G PIhpWypNxadUuGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounI Cjjr8iQTT3NUkxOFOhu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjI GSvRRqpI1mQq14M0/ywqwWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8 /UswDQYJKoZIhvcNAQEFBQADggEBANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16q EUi25Qijs8o9YU3TRgmzPsOg42NVG/K676054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeY BN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8suWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUM HaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRWMZXQZ4mFK/lspl1GnQyqguSZUd1wt9tW PWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY24GzBBzFH6SAbxUgyd4MiAod1mZV 4vxIySkmaeAxggH+MIIB+gIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzIC EGZgT+TGYtW+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgc5Gf VUePA797dsxgqOXEnkQgCeMaXYFeW+IWIQIjqMkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTQxMTMwMjIxNjU3WjANBgkqhkiG9w0BAQEFAASCAQAzR32D HYk6ZAcIq1MvFqTbMVj+2dDEBha14OeJN1LO0uOl7Viy8hTPEUXDtAt1YCYNgLYYhquvCX0m eQol4RCUqZbqxcWP8RJfRc/SN1d9cdAs8iyPz2X7eRWVutcSvuvIl1+co4edwaiby/Ehan9r c9f6fAN69KyIDCLlcLvfAAkViANOK2W19fS33DH50LW/bU8R/RAy7OuFgvm6JSevVTck+/RJ NdWsITjwkkpj1qpOPdAoFhjNVoKLgHplkfRajcsEWrC7ZY+WuyoHfZQfp/TXx6El0khzbAF2 LOEfe/OpZf9CDhTWSNXJM6OQhX2vKOH1RwQ3RNyjD3c/qwtF --B_3500230617_7874043--