From nobody Thu Sep 1 02:01:43 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4127512D803; Thu, 1 Sep 2016 02:01:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147272050222.10168.8825549827660675944.idtracker@ietfa.amsl.com> Date: Thu, 01 Sep 2016 02:01:42 -0700 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org Subject: [IPsec] Benoit Claise's No Objection on charter-ietf-ipsecme-10-01: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 09:01:42 -0000 Benoit Claise has entered the following ballot position for charter-ietf-ipsecme-10-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please provide some milestones along with dates, as guidance so that all documents are finished by Dec 2017. Otherwise this text below becomes a blanket statement, not paid attention to. This charter will expire in December 2017. If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Hint: the current charter says This charter will expire in December 2015 (a year from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. From nobody Thu Sep 1 02:35:50 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106B612D8DE for ; Thu, 1 Sep 2016 02:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXqHCCaalmZ3 for ; Thu, 1 Sep 2016 02:35:35 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6933912D8A3 for ; Thu, 1 Sep 2016 02:35:34 -0700 (PDT) Received: (qmail 18054 invoked from network); 1 Sep 2016 11:35:31 +0200 Received: from p5dec2a74.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.42.116) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 1 Sep 2016 11:35:31 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <3EAA1FDC-D534-4512-B845-905DFF1F425C@apple.com> Date: Thu, 1 Sep 2016 11:35:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147264035968.5285.5678053907364382538.idtracker@ietfa.amsl.com> <22470.50740.674721.131053@fireball.acr.fi> <1F2E47DA-98F5-44C2-8EE6-E185F2AC8855@kuehlewind.net> <22470.52172.370022.168002@fireball.acr.fi> <80F0837E-9F50-4A46-A35F-27D45251253D@gmail.com> <2FE3792A-D7D0-43F9-ACC4-0DCB69AB038E@apple.com> <3EAA1FDC-D534-4512-B845-905DFF1F425C@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ipsecme-chairs@ietf.org, "ipsecme-chairs@tools.ietf.org" , Yoav Nir , IPsecME WG , Kathleen Moriarty , Tero Kivinen , The IESG Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?ipsecme-10-00=3A_=28with_BLOCK=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 09:35:48 -0000 Yes, that=E2=80=99s fine for me. I would say that providing guidance = means that you make one suggestion what to do but don=E2=80=99t specify = a mandatory behavior. Mirja > Am 01.09.2016 um 05:13 schrieb Tommy Pauly : >=20 > Hi Kathleen, >=20 >> On Aug 31, 2016, at 6:53 PM, Kathleen Moriarty = wrote: >>=20 >> Tommy, >>=20 >> On Wed, Aug 31, 2016 at 10:30 AM, Tommy Pauly = wrote: >>>=20 >>>> On Aug 31, 2016, at 6:41 AM, Mirja Kuehlewind (IETF) = wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> thanks for providing the reference to the draft. That was very = helpful and confirmed my initial assumption that you don=E2=80=99t want = to =E2=80=9Achange=E2=80=98 TCP. So this work seems to be fine in this = group, however, the wording in the charter is very misleading. What's = about the following? >>>>=20 >>>> "There have been middle boxes blocking IKE negotiation over UDP. To >>>> make IKE work in these environments, IKE packets need to be >>>> encapsulated in ESP over TCP. Therefore the group will define a = mechanism to >>>> use IKE and IPsec over TCP. Further the group will provide guidance >>>> how to detect when IKE cannot be negotiated over UDP and TCP as a = fallback should be used.=E2=80=9C >>>>=20 >>>> I also removed some redundancy and added a point that guidance is = needed to detect blocking. We could still at the current draft as a = starting point=E2=80=A6 >>>=20 >>> "IKE packets need to be encapsulated in ESP over TCP" is not = correct, since IKE does not run over ESP. IKE and ESP packets run = alongside one another in the stream, as they do when using UDP = encapsulation. >>>=20 >>> How about: >>>=20 >>> "There have been middle boxes blocking IKE negotiation over UDP. To >>> make IKE work in these environments, both IKE packets and tunneled = ESP >>> packets need to be encapsulated in TCP. Therefore the group will = define >>> a mechanism to use IKE and IPsec over TCP, and define the scenarios >>> in which it is appropriate to use this method." >>=20 >> Are you okay with Tero's proposed wording since Mirja has agreed to >> it. The suggested wording is: >>=20 >> There have been middle boxes blocking IKE negotiation over UDP. To >> make IKE work in these environments, IKE and ESP packets need to be >> transmitted over TCP. Therefore the group will define a mechanism to >> use IKE and IPsec over TCP. Further the group will provide guidance >> how to detect when IKE cannot be negotiated over UDP and TCP as a >> fallback should be used. >=20 > The final sentence seems like it's missing a word after "guidance": >=20 > "Further the group will provide guidance > how to detect when IKE cannot be negotiated over UDP and TCP as a > fallback should be used." >=20 > How about: >=20 > "The group will also provide guidance on how to detect when IKE cannot = be negotiated over UDP, and TCP should be used as a fallback". >=20 > =46rom a content perspective, I am fine with this as long as the = primary draft leaves the algorithm as a fairly open-ended suggestion. I = think it is appropriate to say that the IKE_SA_INIT should be sent over = UDP several times, after which point a fallback to TCP is appropriate if = so configured on the device (and that this fallback may be sooner if = there is historical reason to believe it is necessary). Any more = specifics about timing and how to measure expected response times, etc, = would be out of scope. Does that work? >=20 > Thanks, > Tommy >=20 >>=20 >> Sorry for my delayed response to make sure this was addressed, I was >> off today and driving for a good portion of the day. >>=20 >> Thanks, >> Kathleen >>=20 >>>=20 >>> The draft covers the applicability of TCP encapsulation, but I = strongly believe that specific algorithm for fallback is out of scope. = This will be highly context-dependent, and we will have different = algorithms for different devices and scenarios. I have planned on = writing an informational draft as a follow-on to describe the methods we = use, but that should be independent of the protocol to define the = IKE/ESP messages in a stream, which is a much more general protocol. >>>=20 >>> Thanks, >>> Tommy >>>=20 >>>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>> Am 31.08.2016 um 15:17 schrieb Yoav Nir : >>>>>=20 >>>>>=20 >>>>>> On 31 Aug 2016, at 3:21 PM, Tero Kivinen wrote: >>>>>>=20 >>>>>> Mirja Kuehlewind (IETF) writes: >>>>>>> thanks for the reply. Very helpful background info. Maybe even = put >>>>>>> more information in the charter text. >>>>>>=20 >>>>>> I think it belongs to the actual draft, not to the charter, = perhaps we >>>>>> should put the draft-ietf-ipsecme-tcp-encaps in the charter, as >>>>>> a working draft. >>>>>>=20 >>>>>>> When you say "the 3gpp specification did not consider or specify = all >>>>>>> needed things for the protocol=E2=80=9C, can you be more = specific here? >>>>>>=20 >>>>>> 3GPP just said that we make TCP tunnel, put 16-bit length header = in >>>>>> front telling the length of the IKE or ESP packet coming after = that, >>>>>> and then we put either ESP packet directly, or 4-bytes of zeros >>>>>> (Non-ESP marker we use in UDP encapsulation) and IKE packet. >>>>>>=20 >>>>>> There is also keepalive timer sending packets over TCP to keep it >>>>>> alive (again similar what we have in UDP). >>>>>=20 >>>>> One more bit of information: some vendors have had a = non-standardized version of this or something similar for years. My = employer has had it since 2003, except that the header is a bit = different. The pretty ubiquitous SSL VPNs do pretty much the same except = that they encrypt IP packets plus headers into TLS records rather than = ESP packets before streaming them over TCP. >>>>>=20 >>>>> Perhaps =E2=80=9CTCP tunnel=E2=80=9D is a misleading term because = the TCP does not tunnel. That is part of the function of ESP. Perhaps we = should be saying =E2=80=9CTCP streaming of ESP and IKE packets=E2=80=9D >>>>>=20 >>>>> Yoav >>>>=20 >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>=20 >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >=20 From nobody Thu Sep 1 02:39:33 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4770312D8E9 for ; Thu, 1 Sep 2016 02:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXCYRZ1M4elh for ; Thu, 1 Sep 2016 02:39:24 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6580B12D8DE for ; Thu, 1 Sep 2016 02:39:24 -0700 (PDT) Received: (qmail 18220 invoked from network); 1 Sep 2016 11:39:22 +0200 Received: from p5dec2a74.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.42.116) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 1 Sep 2016 11:39:21 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Thu, 1 Sep 2016 11:39:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147267220071.31935.11277403442737346313.idtracker@ietfa.amsl.com> <213F05E8-C281-493F-8229-F9529949DAD9@kuehlewind.net> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ipsec@ietf.org" , "ipsecme-chairs@tools.ietf.org" , ipsecme-chairs@ietf.org, Alissa Cooper , The IESG Subject: Re: [IPsec] Alissa Cooper's No Objection on charter-ietf-ipsecme-10-00: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 09:39:27 -0000 I thought the way we usually do this, is to have milestones with a = timeline and have a sentence saying: When these milestones have been = reached the working group will recharter or close. Given the planned work and the rather near-time date, I can already say = that they have to extend this date which in this case means a full = recharter and processing. While updating milestones can be done by the = chairs. Mirja > Am 01.09.2016 um 03:39 schrieb Kathleen Moriarty = : >=20 > On Wed, Aug 31, 2016 at 6:05 PM, Mirja Kuehlewind (IETF) > wrote: >> That=E2=80=99s actually a good point that I forgot to mention as = well. Actually my question is, why is this limited needed at all? >=20 > The WG has had this in their charter for some time. The previous > chairs with the WG have wanted to keep a window set since this is a > maintenance WG as a way to prevent it from living on beyond it's > usefulness. They believe that it's okay to shutdown the WG if it > dwindles and would like to have ways to determine if that is > necessary. They are also fine with a temporary closing to then reopen > as another follow on effort. This is a follow on WG itself after the > original WG responsible for IPsec had closed for a few years. >=20 >>=20 >>=20 >>> Am 31.08.2016 um 21:36 schrieb Alissa Cooper : >>>=20 >>> Alissa Cooper has entered the following ballot position for >>> charter-ietf-ipsecme-10-00: No Objection >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> This seems like a lot of documents for a 16-month window based on = this >>> group's past publication rate. Good to be ambitious, but I'm just >>> wondering how realistic this is. >=20 > Yes, it's ambitious. I'll leave that to the chairs to respond. In > the past they have tried to keep the date to a reasonable one to > complete work or to close if the WG became too inactive since it's > along-standing one. It has gotten some new life recently, so I don't > expect this WG to close too soon. >=20 >>>=20 >>>=20 >>=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen >=20 From nobody Thu Sep 1 04:04:27 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1252512D922; Thu, 1 Sep 2016 04:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABpzvfGLmWjJ; Thu, 1 Sep 2016 04:04:15 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EE8612D920; Thu, 1 Sep 2016 04:04:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2289CBE7C; Thu, 1 Sep 2016 12:04:14 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs45h_WJuo6V; Thu, 1 Sep 2016 12:04:14 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7C3C3BE74; Thu, 1 Sep 2016 12:04:13 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1472727853; bh=w9NfbYqGrZVJ5Sq2ewrae36hmfbxMchR6dY1n5u3QF8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=n+z4OdRIkEvkLKvhJdjM1S9+61YQn2KsPSY1Y6N0PjaVmBNkdBuUtr+85+N3jmJBA fgHbIGb7KJM8XWujuStlEKOLk3ZZEBtE/Ze1nMHMzqU5xjInizaGsmDUN7DKoW34JK Mk90ta57YcdoxDWDpKZ/8D8I1XS+6ZpjS33A0XPk= To: "Mirja Kuehlewind (IETF)" , Kathleen Moriarty References: <147267220071.31935.11277403442737346313.idtracker@ietfa.amsl.com> <213F05E8-C281-493F-8229-F9529949DAD9@kuehlewind.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <722d1a29-0e70-e653-eaf2-11a9002ab293@cs.tcd.ie> Date: Thu, 1 Sep 2016 12:04:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060304000403080700070303" Archived-At: Cc: "ipsec@ietf.org" , "ipsecme-chairs@tools.ietf.org" , ipsecme-chairs@ietf.org, Alissa Cooper , The IESG Subject: Re: [IPsec] Alissa Cooper's No Objection on charter-ietf-ipsecme-10-00: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 11:04:20 -0000 This is a cryptographically signed message in MIME format. --------------ms060304000403080700070303 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/09/16 10:39, Mirja Kuehlewind (IETF) wrote: > I thought the way we usually do this, is to have milestones with a > timeline and have a sentence saying: When these milestones have been > reached the working group will recharter or close. Yep, that is the usual approach. The ipsecme wg however have not taken the usual approach for quite a while now and that's also ok. As Kathleen explained they've tended to have a drop dead date in the charter as a way to motivate folks to have made sufficient progress by that date. I think they've come close to closing for that reason a couple of times over the last few years. IIRC, that was started because there was a fear of having loads and loads of seemingly reasonable work items, few of which were of enough interest to be finished in a timely manner. (I'm open to correction on that though.) One can of course wonder if that's the best approach, but I think it's perfectly fine that different WGs use different ways of doing things like this. It's also fine that the IESG ask about it of course, but we (the IESG) should also be careful to not give the impression we're trying to shoe-horn all WGs into using the same management techniques. (I don't think that's what's happening, but one could get that impression maybe.) Cheers, S. >=20 > Given the planned work and the rather near-time date, I can already > say that they have to extend this date which in this case means a > full recharter and processing. While updating milestones can be done > by the chairs. >=20 > Mirja >=20 >=20 >> Am 01.09.2016 um 03:39 schrieb Kathleen Moriarty >> : >>=20 >> On Wed, Aug 31, 2016 at 6:05 PM, Mirja Kuehlewind (IETF)=20 >> wrote: >>> That=E2=80=99s actually a good point that I forgot to mention as well= =2E >>> Actually my question is, why is this limited needed at all? >>=20 >> The WG has had this in their charter for some time. The previous=20 >> chairs with the WG have wanted to keep a window set since this is >> a maintenance WG as a way to prevent it from living on beyond it's=20 >> usefulness. They believe that it's okay to shutdown the WG if it=20 >> dwindles and would like to have ways to determine if that is=20 >> necessary. They are also fine with a temporary closing to then >> reopen as another follow on effort. This is a follow on WG itself >> after the original WG responsible for IPsec had closed for a few >> years. >>=20 >>>=20 >>>=20 >>>> Am 31.08.2016 um 21:36 schrieb Alissa Cooper >>>> : >>>>=20 >>>> Alissa Cooper has entered the following ballot position for=20 >>>> charter-ietf-ipsecme-10-00: No Objection >>>>=20 >>>> When responding, please keep the subject line intact and reply >>>> to all email addresses included in the To and CC lines. (Feel >>>> free to cut this introductory paragraph, however.) >>>>=20 >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found >>>> here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ >>>>=20 >>>>=20 >>>>=20 >>>> --------------------------------------------------------------------= -- >>>> >>>>=20 COMMENT: >>>> --------------------------------------------------------------------= -- >>>> >>>> >>>>=20 This seems like a lot of documents for a 16-month window based on this >>>> group's past publication rate. Good to be ambitious, but I'm >>>> just wondering how realistic this is. >>=20 >> Yes, it's ambitious. I'll leave that to the chairs to respond. >> In the past they have tried to keep the date to a reasonable one >> to complete work or to close if the WG became too inactive since >> it's along-standing one. It has gotten some new life recently, so >> I don't expect this WG to close too soon. >>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >>=20 >> -- >>=20 >> Best regards, Kathleen >>=20 >=20 --------------ms060304000403080700070303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5MDEx MTA0MTNaMC8GCSqGSIb3DQEJBDEiBCBuvaXMW/R38Glls22wR0cDBQugZuQSB6mw555gznRk sjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAIOJHEeCKSbHIMoFtJLHTL08W7pjUojPM1MEpfMOjXi9n0kekOGfOm bm1cvfBrDjBUX46yniabbK1+HXFtIUnl9sTNQgVtm4b4fXesMlTBWnwOLQhD7nFSgGTTFQw7 jM0jTDavS8pLx8jbroRLHoU/J/Fjzeq3XHDQ5qjXcmSFbUvr/VV/TBO/9+ez8L8jxLnc7lm7 WjoODA3IotIJTX4GVD6Io20ny3HFJsf40xF7wJc375axyztGxtoYYMr7XZqKEd8vGxGpR9sI Jz9JOusbumocb4iOgj+GjD92GnzfakuMj50T6rAzXVXM1FUj4w9B30m6+LuYD0pKouxLoCqG AAAAAAAA --------------ms060304000403080700070303-- From nobody Thu Sep 1 04:46:36 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD0812D932; Thu, 1 Sep 2016 04:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjUXzSh7ZS3X; Thu, 1 Sep 2016 04:46:25 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74D1112DA73; Thu, 1 Sep 2016 04:34:53 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id v123so81055289qkh.2; Thu, 01 Sep 2016 04:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jDRKmDKRYYrLnCRPf+nuVWFDVo9s4faVGKWNfl7sd9M=; b=DShIgMEppWp2iBjWaVS5SbNQMkqVepVtvXe3KV9KuPmkkcdHIOfc8s7NnqqpsmzOL6 3O8lzIJ6cAaJon0gNhDt+xGCuomfPg0nrneUyfCLnI08mgj1Bd/4z936947P2YTY6DZZ t0/aSbnDuqPWzBp7G/vYL0Ix8EbkQBult0m8DbALl5dTdWPJwszF+6cCsFK+LxPgmFEO BnHZJZiugDWMzDmbPFz7yYkOHu6XzKaBJhKOSx20xwWyir0zyiB/I692bFmRnsRKAtvG tdhXYm2eSeWeZ2y8zoA8bYRqasUcHeicRduTkiKJOIlZnu4BinuxIYtU4sVk6LuLAV4t 9WBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jDRKmDKRYYrLnCRPf+nuVWFDVo9s4faVGKWNfl7sd9M=; b=eZsC5FC8OIPoz6WYsOZY8i4AuQuBO8LP14FxY0qKUM8+wb7rytnxuTAh0JV8jFUTXh wf6yRI4m/MLCaPH9SYNd0mo64vBCnm2lbbXWnNURj+JAHg2FWH/GnmTOZh5+A5cdfSKr Xyuh7/HfodvI3BAo2UeiMTPwpPfxSScs8VWOle4pxXTRSIceN+lPU9vcTpZEii6gRpd8 EdfbMDRICTtfyeXaGXnavifahmzz8WUSZRHeQoIeEpEyT1JUMclAv7v0fXHm3Ev3BRKp aLIBZ6HJyFBFsRaEDYZj/23oiY/bJF4n9CJ0CwxkxcDTKgr1zYwKkZn7nv2nHgszi+CF O18g== X-Gm-Message-State: AE9vXwOzlnbLYWkPnBDCjSEqNET3D0k1FtQWlgfU2OBJyL4jaTaQwB+evDN8RZ91KUhD2g== X-Received: by 10.55.184.198 with SMTP id i189mr16295221qkf.96.1472729692446; Thu, 01 Sep 2016 04:34:52 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id l32sm2527147qta.23.2016.09.01.04.34.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 01 Sep 2016 04:34:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G35) In-Reply-To: <722d1a29-0e70-e653-eaf2-11a9002ab293@cs.tcd.ie> Date: Thu, 1 Sep 2016 07:34:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1D5064E0-8B5C-483A-BD5C-A3A4259ED605@gmail.com> References: <147267220071.31935.11277403442737346313.idtracker@ietfa.amsl.com> <213F05E8-C281-493F-8229-F9529949DAD9@kuehlewind.net> <722d1a29-0e70-e653-eaf2-11a9002ab293@cs.tcd.ie> To: Stephen Farrell Archived-At: Cc: ipsecme-chairs@ietf.org, "ipsecme-chairs@tools.ietf.org" , Alissa Cooper , "ipsec@ietf.org" , "Mirja Kuehlewind \(IETF\)" , The IESG Subject: Re: [IPsec] Alissa Cooper's No Objection on charter-ietf-ipsecme-10-00: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 11:46:30 -0000 Sent from my iPhone > On Sep 1, 2016, at 7:04 AM, Stephen Farrell wr= ote: >=20 >=20 >=20 >> On 01/09/16 10:39, Mirja Kuehlewind (IETF) wrote: >> I thought the way we usually do this, is to have milestones with a >> timeline and have a sentence saying: When these milestones have been >> reached the working group will recharter or close. >=20 > Yep, that is the usual approach. The ipsecme wg however have > not taken the usual approach for quite a while now and that's > also ok. As Kathleen explained they've tended to have a drop > dead date in the charter as a way to motivate folks to have made > sufficient progress by that date. I think they've come close to > closing for that reason a couple of times over the last few > years. >=20 > IIRC, that was started because there was a fear of having > loads and loads of seemingly reasonable work items, few of > which were of enough interest to be finished in a timely manner. > (I'm open to correction on that though.) >=20 Yes and they've also reconsidered drafts that have been accepted. If they t= hink an approach is not going to be feasible after more research, they've dr= opped the work. > One can of course wonder if that's the best approach, but I > think it's perfectly fine that different WGs use different ways > of doing things like this. It's also fine that the IESG ask about > it of course, but we (the IESG) should also be careful to not give > the impression we're trying to shoe-horn all WGs into using the > same management techniques. (I don't think that's what's happening, > but one could get that impression maybe.) I think this WG and SACM are my only two with a deadline and this one is fro= m the WG themselves. Thanks, Kathleen=20 >=20 > Cheers, > S. >=20 >>=20 >> Given the planned work and the rather near-time date, I can already >> say that they have to extend this date which in this case means a >> full recharter and processing. While updating milestones can be done >> by the chairs. >>=20 >> Mirja >>=20 >>=20 >>> Am 01.09.2016 um 03:39 schrieb Kathleen Moriarty >>> : >>>=20 >>> On Wed, Aug 31, 2016 at 6:05 PM, Mirja Kuehlewind (IETF)=20 >>> wrote: >>>> That=E2=80=99s actually a good point that I forgot to mention as well. >>>> Actually my question is, why is this limited needed at all? >>>=20 >>> The WG has had this in their charter for some time. The previous=20 >>> chairs with the WG have wanted to keep a window set since this is >>> a maintenance WG as a way to prevent it from living on beyond it's=20 >>> usefulness. They believe that it's okay to shutdown the WG if it=20 >>> dwindles and would like to have ways to determine if that is=20 >>> necessary. They are also fine with a temporary closing to then >>> reopen as another follow on effort. This is a follow on WG itself >>> after the original WG responsible for IPsec had closed for a few >>> years. >>>=20 >>>>=20 >>>>=20 >>>>> Am 31.08.2016 um 21:36 schrieb Alissa Cooper >>>>> : >>>>>=20 >>>>> Alissa Cooper has entered the following ballot position for=20 >>>>> charter-ietf-ipsecme-10-00: No Objection >>>>>=20 >>>>> When responding, please keep the subject line intact and reply >>>>> to all email addresses included in the To and CC lines. (Feel >>>>> free to cut this introductory paragraph, however.) >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The document, along with other ballot positions, can be found >>>>> here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> ----------------------------------------------------------------------= > COMMENT: >>>>> ----------------------------------------------------------------------= > This seems like a lot of documents for a 16-month window based on this >>>>> group's past publication rate. Good to be ambitious, but I'm >>>>> just wondering how realistic this is. >>>=20 >>> Yes, it's ambitious. I'll leave that to the chairs to respond. >>> In the past they have tried to keep the date to a reasonable one >>> to complete work or to close if the WG became too inactive since >>> it's along-standing one. It has gotten some new life recently, so >>> I don't expect this WG to close too soon. >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>>=20 >>> Best regards, Kathleen >=20 From nobody Thu Sep 1 04:47:31 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F57312D962; Thu, 1 Sep 2016 04:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJtKjZ8TVqMN; Thu, 1 Sep 2016 04:47:21 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31A112DA94; Thu, 1 Sep 2016 04:36:59 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id v123so81107755qkh.2; Thu, 01 Sep 2016 04:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JPmWdWo9jv/1xouX5fxCxKd5JPnrs8em697A+oZWiQA=; b=lCcPL+zhyZOPNZkoKOvaOLLFmg6sPUtlfbLNXrkVomwZNefJz9DiQ8sFd6bVOEWjt7 SxpIjDPbJRpGLnW6y1diffasg7scBkuafXQxnkv2Nl56sniKNt4NHzrK1H2w9K0/q7ez xe524hgiMASYM6dHPbN8GxPRObrYgJ/zSaPdzcwwMGAOKqklZgGJCPhtU2l/YX0+i+Zc E6kG4iPtpKu/EKYR2C7+evzLmU3xf+HEGoNbUJpTYrrtx9HfkKMaSydFSz1IyY8Ao+gE RAnex/wTKnyci5L3TjChM4NmN1BMAvPh9yFqemjOh1XRwXTsv5kIA1R4toXVUts3GNwM uaaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JPmWdWo9jv/1xouX5fxCxKd5JPnrs8em697A+oZWiQA=; b=i/DztoBPpZZYUJ+RzOjuY5b+g7L407R9RDxzXjIdcSl4hyNrGrzd0rSFZ4LTturlbP T377Mp6XzP7nELijTeulXTiQnopLjFO40dvUEmsgjUyKPeBUXwxTrXQK2cTdOdkq++92 DuCjdxqw/eASOa3/vtx+W4oLyK31kp0Xob03+TT3PQMvglmLqw/Y6YFQMijCRl5HnW8l Y7Ll59b9aOvpaMrs3rXZjiQNzZn+D4qkc9MAwKXE/mgD7unGiR/Hv+bG/FCCbgq5bafu gawWOiLyzCRU+5D0ZcYcT2EMa9lk38bOb3yBp9bEHF2+pCjpZta5ti1LYPaoM7nctCUJ a6RQ== X-Gm-Message-State: AE9vXwOPOCEP2Nq87nEnmKVswz6px8kXJMbhzlEJWthJL0PbUW1OZ6EzVIBA4Joy3O2s3g== X-Received: by 10.55.16.65 with SMTP id a62mr3755208qkh.226.1472729818787; Thu, 01 Sep 2016 04:36:58 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id n128sm2531263qkn.21.2016.09.01.04.36.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 01 Sep 2016 04:36:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Thu, 1 Sep 2016 07:36:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147264035968.5285.5678053907364382538.idtracker@ietfa.amsl.com> <22470.50740.674721.131053@fireball.acr.fi> <1F2E47DA-98F5-44C2-8EE6-E185F2AC8855@kuehlewind.net> <22470.52172.370022.168002@fireball.acr.fi> <80F0837E-9F50-4A46-A35F-27D45251253D@gmail.com> <2FE3792A-D7D0-43F9-ACC4-0DCB69AB038E@apple.com> <3EAA1FDC-D534-4512-B845-905DFF1F425C@apple.com> To: "Mirja Kuehlewind (IETF)" Archived-At: Cc: ipsecme-chairs@ietf.org, "ipsecme-chairs@tools.ietf.org" , Yoav Nir , IPsecME WG , Tero Kivinen , Tommy Pauly , The IESG Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?ipsecme-10-00=3A_=28with_BLOCK=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 11:47:24 -0000 Sent from my iPhone > On Sep 1, 2016, at 5:35 AM, Mirja Kuehlewind (IETF) w= rote: >=20 > Yes, that=E2=80=99s fine for me. I would say that providing guidance means= that you make one suggestion what to do but don=E2=80=99t specify a mandato= ry behavior. Ok, I'll update the text before our call today. This section does read bett= er now. Thank you, Kathleen=20 >=20 > Mirja >=20 >=20 >> Am 01.09.2016 um 05:13 schrieb Tommy Pauly : >>=20 >> Hi Kathleen, >>=20 >>> On Aug 31, 2016, at 6:53 PM, Kathleen Moriarty wrote: >>>=20 >>> Tommy, >>>=20 >>>> On Wed, Aug 31, 2016 at 10:30 AM, Tommy Pauly wrote:= >>>>=20 >>>>> On Aug 31, 2016, at 6:41 AM, Mirja Kuehlewind (IETF) wrote: >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> thanks for providing the reference to the draft. That was very helpful= and confirmed my initial assumption that you don=E2=80=99t want to =E2=80=9A= change=E2=80=98 TCP. So this work seems to be fine in this group, however, t= he wording in the charter is very misleading. What's about the following? >>>>>=20 >>>>> "There have been middle boxes blocking IKE negotiation over UDP. To >>>>> make IKE work in these environments, IKE packets need to be >>>>> encapsulated in ESP over TCP. Therefore the group will define a mechan= ism to >>>>> use IKE and IPsec over TCP. Further the group will provide guidance >>>>> how to detect when IKE cannot be negotiated over UDP and TCP as a fall= back should be used.=E2=80=9C >>>>>=20 >>>>> I also removed some redundancy and added a point that guidance is need= ed to detect blocking. We could still at the current draft as a starting poi= nt=E2=80=A6 >>>>=20 >>>> "IKE packets need to be encapsulated in ESP over TCP" is not correct, s= ince IKE does not run over ESP. IKE and ESP packets run alongside one anothe= r in the stream, as they do when using UDP encapsulation. >>>>=20 >>>> How about: >>>>=20 >>>> "There have been middle boxes blocking IKE negotiation over UDP. To >>>> make IKE work in these environments, both IKE packets and tunneled ESP >>>> packets need to be encapsulated in TCP. Therefore the group will define= >>>> a mechanism to use IKE and IPsec over TCP, and define the scenarios >>>> in which it is appropriate to use this method." >>>=20 >>> Are you okay with Tero's proposed wording since Mirja has agreed to >>> it. The suggested wording is: >>>=20 >>> There have been middle boxes blocking IKE negotiation over UDP. To >>> make IKE work in these environments, IKE and ESP packets need to be >>> transmitted over TCP. Therefore the group will define a mechanism to >>> use IKE and IPsec over TCP. Further the group will provide guidance >>> how to detect when IKE cannot be negotiated over UDP and TCP as a >>> fallback should be used. >>=20 >> The final sentence seems like it's missing a word after "guidance": >>=20 >> "Further the group will provide guidance >> how to detect when IKE cannot be negotiated over UDP and TCP as a >> fallback should be used." >>=20 >> How about: >>=20 >> "The group will also provide guidance on how to detect when IKE cannot be= negotiated over UDP, and TCP should be used as a fallback". >>=20 >> =46rom a content perspective, I am fine with this as long as the primary d= raft leaves the algorithm as a fairly open-ended suggestion. I think it is a= ppropriate to say that the IKE_SA_INIT should be sent over UDP several times= , after which point a fallback to TCP is appropriate if so configured on the= device (and that this fallback may be sooner if there is historical reason t= o believe it is necessary). Any more specifics about timing and how to measu= re expected response times, etc, would be out of scope. Does that work? >>=20 >> Thanks, >> Tommy >>=20 >>>=20 >>> Sorry for my delayed response to make sure this was addressed, I was >>> off today and driving for a good portion of the day. >>>=20 >>> Thanks, >>> Kathleen >>>=20 >>>>=20 >>>> The draft covers the applicability of TCP encapsulation, but I strongly= believe that specific algorithm for fallback is out of scope. This will be h= ighly context-dependent, and we will have different algorithms for different= devices and scenarios. I have planned on writing an informational draft as a= follow-on to describe the methods we use, but that should be independent of= the protocol to define the IKE/ESP messages in a stream, which is a much mo= re general protocol. >>>>=20 >>>> Thanks, >>>> Tommy >>>>=20 >>>>>=20 >>>>> Mirja >>>>>=20 >>>>>=20 >>>>>> Am 31.08.2016 um 15:17 schrieb Yoav Nir : >>>>>>=20 >>>>>>=20 >>>>>>> On 31 Aug 2016, at 3:21 PM, Tero Kivinen wrote: >>>>>>>=20 >>>>>>> Mirja Kuehlewind (IETF) writes: >>>>>>>> thanks for the reply. Very helpful background info. Maybe even put >>>>>>>> more information in the charter text. >>>>>>>=20 >>>>>>> I think it belongs to the actual draft, not to the charter, perhaps w= e >>>>>>> should put the draft-ietf-ipsecme-tcp-encaps in the charter, as >>>>>>> a working draft. >>>>>>>=20 >>>>>>>> When you say "the 3gpp specification did not consider or specify al= l >>>>>>>> needed things for the protocol=E2=80=9C, can you be more specific h= ere? >>>>>>>=20 >>>>>>> 3GPP just said that we make TCP tunnel, put 16-bit length header in >>>>>>> front telling the length of the IKE or ESP packet coming after that,= >>>>>>> and then we put either ESP packet directly, or 4-bytes of zeros >>>>>>> (Non-ESP marker we use in UDP encapsulation) and IKE packet. >>>>>>>=20 >>>>>>> There is also keepalive timer sending packets over TCP to keep it >>>>>>> alive (again similar what we have in UDP). >>>>>>=20 >>>>>> One more bit of information: some vendors have had a non-standardized= version of this or something similar for years. My employer has had it sinc= e 2003, except that the header is a bit different. The pretty ubiquitous SSL= VPNs do pretty much the same except that they encrypt IP packets plus heade= rs into TLS records rather than ESP packets before streaming them over TCP. >>>>>>=20 >>>>>> Perhaps =E2=80=9CTCP tunnel=E2=80=9D is a misleading term because the= TCP does not tunnel. That is part of the function of ESP. Perhaps we should= be saying =E2=80=9CTCP streaming of ESP and IKE packets=E2=80=9D >>>>>>=20 >>>>>> Yoav >>>>>=20 >>>>> _______________________________________________ >>>>> IPsec mailing list >>>>> IPsec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>=20 >>>=20 >>>=20 >>> --=20 >>>=20 >>> Best regards, >>> Kathleen >=20 From nobody Thu Sep 1 05:14:31 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D5212D197; Thu, 1 Sep 2016 05:14:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147273206803.10104.6877709819154813871.idtracker@ietfa.amsl.com> Date: Thu, 01 Sep 2016 05:14:28 -0700 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org Subject: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_charte?= =?utf-8?q?r-ietf-ipsecme-10-01=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 12:14:28 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-ipsecme-10-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for changing the text on TCP! From nobody Thu Sep 1 05:54:42 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B07C12DAB3 for ; Thu, 1 Sep 2016 05:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHKoyuq51KI9 for ; Thu, 1 Sep 2016 05:54:36 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A456712D94D for ; Thu, 1 Sep 2016 05:38:02 -0700 (PDT) Received: (qmail 26133 invoked from network); 1 Sep 2016 14:31:19 +0200 Received: from p5dec2a74.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.42.116) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 1 Sep 2016 14:31:18 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <1D5064E0-8B5C-483A-BD5C-A3A4259ED605@gmail.com> Date: Thu, 1 Sep 2016 14:29:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147267220071.31935.11277403442737346313.idtracker@ietfa.amsl.com> <213F05E8-C281-493F-8229-F9529949DAD9@kuehlewind.net> <722d1a29-0e70-e653-eaf2-11a9002ab293@cs.tcd.ie> <1D5064E0-8B5C-483A-BD5C-A3A4259ED605@gmail.com> To: Kathleen Moriarty , Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ipsec@ietf.org" , "ipsecme-chairs@tools.ietf.org" , ipsecme-chairs@ietf.org, Alissa Cooper , The IESG Subject: Re: [IPsec] Alissa Cooper's No Objection on charter-ietf-ipsecme-10-00: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 12:54:40 -0000 I don=E2=80=99t know. I mean I don=E2=80=99t want to enforce a certain = management strategy but in this case it seems to me they actually use = the wrong tool here. Milestones with deadlines are what we have to set = up some time pressure. They are often not really used by the chairs this = way, but they could still say something like: if you don=E2=80=99t = deliver in time, we=E2=80=99ll go ahead and request the closing of the = wg no matter if you are done or not. Requiring a recharter process over = and over is just additional load on the IESG with no gain. I know it=E2=80= =99s very low load but as I said I think it=E2=80=99s just the wrong = tool they use. And would rather understand to use this mechanism by an AD to build up = some additional pressure if that seems to be needed but having this = requested by the wg/chairs I understand even less=E2=80=A6 Mirja > Am 01.09.2016 um 13:34 schrieb kathleen.moriarty.ietf@gmail.com: >=20 >=20 >=20 > Sent from my iPhone >=20 >> On Sep 1, 2016, at 7:04 AM, Stephen Farrell = wrote: >>=20 >>=20 >>=20 >>> On 01/09/16 10:39, Mirja Kuehlewind (IETF) wrote: >>> I thought the way we usually do this, is to have milestones with a >>> timeline and have a sentence saying: When these milestones have been >>> reached the working group will recharter or close. >>=20 >> Yep, that is the usual approach. The ipsecme wg however have >> not taken the usual approach for quite a while now and that's >> also ok. As Kathleen explained they've tended to have a drop >> dead date in the charter as a way to motivate folks to have made >> sufficient progress by that date. I think they've come close to >> closing for that reason a couple of times over the last few >> years. >=20 >>=20 >> IIRC, that was started because there was a fear of having >> loads and loads of seemingly reasonable work items, few of >> which were of enough interest to be finished in a timely manner. >> (I'm open to correction on that though.) >>=20 > Yes and they've also reconsidered drafts that have been accepted. If = they think an approach is not going to be feasible after more research, = they've dropped the work. >=20 >> One can of course wonder if that's the best approach, but I >> think it's perfectly fine that different WGs use different ways >> of doing things like this. It's also fine that the IESG ask about >> it of course, but we (the IESG) should also be careful to not give >> the impression we're trying to shoe-horn all WGs into using the >> same management techniques. (I don't think that's what's happening, >> but one could get that impression maybe.) >=20 > I think this WG and SACM are my only two with a deadline and this one = is from the WG themselves. >=20 > Thanks, > Kathleen=20 >>=20 >> Cheers, >> S. >>=20 >>>=20 >>> Given the planned work and the rather near-time date, I can already >>> say that they have to extend this date which in this case means a >>> full recharter and processing. While updating milestones can be done >>> by the chairs. >>>=20 >>> Mirja >>>=20 >>>=20 >>>> Am 01.09.2016 um 03:39 schrieb Kathleen Moriarty >>>> : >>>>=20 >>>> On Wed, Aug 31, 2016 at 6:05 PM, Mirja Kuehlewind (IETF)=20 >>>> wrote: >>>>> That=E2=80=99s actually a good point that I forgot to mention as = well. >>>>> Actually my question is, why is this limited needed at all? >>>>=20 >>>> The WG has had this in their charter for some time. The previous=20= >>>> chairs with the WG have wanted to keep a window set since this is >>>> a maintenance WG as a way to prevent it from living on beyond it's=20= >>>> usefulness. They believe that it's okay to shutdown the WG if it=20= >>>> dwindles and would like to have ways to determine if that is=20 >>>> necessary. They are also fine with a temporary closing to then >>>> reopen as another follow on effort. This is a follow on WG itself >>>> after the original WG responsible for IPsec had closed for a few >>>> years. >>>>=20 >>>>>=20 >>>>>=20 >>>>>> Am 31.08.2016 um 21:36 schrieb Alissa Cooper >>>>>> : >>>>>>=20 >>>>>> Alissa Cooper has entered the following ballot position for=20 >>>>>> charter-ietf-ipsecme-10-00: No Objection >>>>>>=20 >>>>>> When responding, please keep the subject line intact and reply >>>>>> to all email addresses included in the To and CC lines. (Feel >>>>>> free to cut this introductory paragraph, however.) >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The document, along with other ballot positions, can be found >>>>>> here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> = ---------------------------------------------------------------------- >> COMMENT: >>>>>> = ---------------------------------------------------------------------- >> This seems like a lot of documents for a 16-month window based on = this >>>>>> group's past publication rate. Good to be ambitious, but I'm >>>>>> just wondering how realistic this is. >>>>=20 >>>> Yes, it's ambitious. I'll leave that to the chairs to respond. >>>> In the past they have tried to keep the date to a reasonable one >>>> to complete work or to close if the WG became too inactive since >>>> it's along-standing one. It has gotten some new life recently, so >>>> I don't expect this WG to close too soon. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>> Best regards, Kathleen >>=20 >=20 From nobody Thu Sep 1 17:47:38 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 863B612D767; Thu, 1 Sep 2016 17:47:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147277725354.32151.17304929310327640665.idtracker@ietfa.amsl.com> Date: Thu, 01 Sep 2016 17:47:33 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-11.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 00:47:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Algorithm Implementation Requirements and Usage Guidance for IKEv2 Authors : Yoav Nir Tero Kivinen Paul Wouters Daniel Migault Filename : draft-ietf-ipsecme-rfc4307bis-11.txt Pages : 17 Date : 2016-09-01 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for IKEv2 and does minor cleaning up of IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 1 17:52:08 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C0412D7E4 for ; Thu, 1 Sep 2016 17:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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.548] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uuh5-DthX9DN for ; Thu, 1 Sep 2016 17:52:05 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE02D12D7A2 for ; Thu, 1 Sep 2016 17:52:05 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sQLDf4tNJzJsl for ; Fri, 2 Sep 2016 02:52:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1472777522; bh=SkxgibYiOTcN5nz/YQB5oPGF5WaZI2ArhE0zQ3G0Kow=; h=Date:From:To:Subject:In-Reply-To:References; b=W0ye4yCtnleOqrdCviwa2w2w3MoQq0Zlice6XryD6whdKK/jCK2s7Walq1nVBVgdK fjBQS1aZq0iofOiM4z1F4MQutdMnC0YNOAKbeGf4/hoJRF6CL/XKOFQ73ARFx48v09 uqliLFx/5oPhRjH/yTGbT1tdt/VYec2rk4f3wvzA= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id cqQwAKKsmkn6 for ; Fri, 2 Sep 2016 02:52:01 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Fri, 2 Sep 2016 02:52:01 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9022E19C322; Thu, 1 Sep 2016 20:52:00 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 9022E19C322 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 808324163760 for ; Thu, 1 Sep 2016 20:52:00 -0400 (EDT) Date: Thu, 1 Sep 2016 20:52:00 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <147277725354.32151.17304929310327640665.idtracker@ietfa.amsl.com> Message-ID: References: <147277725354.32151.17304929310327640665.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-11.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 00:52:07 -0000 On Thu, 1 Sep 2016, internet-drafts@ietf.org wrote: > Filename : draft-ietf-ipsecme-rfc4307bis-11.txt > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-11 The only change is to make 256-bits a MUST along with 128-bit keys. The exception is ENCR_AES_CCM_8 which is for use with IoT which only has 128-bits keys as a MUST and 256-bit keys as a MAY. That resolves all the issues the authors are aware of, so we believe this document is ready for WGLC. Paul From nobody Thu Sep 1 19:49:59 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1250612D91E for ; Thu, 1 Sep 2016 19:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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.548] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vC46bCbTLnCk for ; Thu, 1 Sep 2016 19:49:56 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B85F12D7DD for ; Thu, 1 Sep 2016 19:49:56 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sQNrf0vDBz3Nw for ; Fri, 2 Sep 2016 04:49:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1472784594; bh=sN9oWLuTLh+6FBTeYo6+XBOVGTAFhjPaUa/IIfAEFT0=; h=Date:From:To:Subject; b=YEehLeg7zpoLzLIEOPd4DXjpIDk9vRSSx6Trsv0mddxllX2edsJCnsugUSS+aVFYy Ab6NIT827b50c0KJ7/A5T8ybvZZI5n486xkPMfGx0a89D1j6lp5+Qj7er4/x3zrHZl PvGSI+tY17N4ZLwHf6GPYJNM2OjVQBeUvk+BDsgs= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Lf0A1gV98mp2 for ; Fri, 2 Sep 2016 04:49:51 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Fri, 2 Sep 2016 04:49:51 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0580519C323; Thu, 1 Sep 2016 22:49:48 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 0580519C323 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E913D4163762 for ; Thu, 1 Sep 2016 22:49:48 -0400 (EDT) Date: Thu, 1 Sep 2016 22:49:48 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] draft-mglt-ipsecme-rfc7321bis-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 02:49:58 -0000 I just published draft-mglt-ipsecme-rfc7321bis-03 (well and -02) (ietf announcement of these seems delayed?) https://tools.ietf.org/html/draft-mglt-ipsecme-rfc7321bis-03 The changes are: - Update 256-bit key sizes to MUST (except IoT) - similar to 4307bis - Add Security Section from RFC7321 - Removed MAY algorithms (RC5, CAST, IDEA, ENCR_AES_CCM_16) - Added note on ENCR_BLOWFISH - Removed notes on removed MAY list entries (CCM & GCM flavours, GMAC, CMAC)) - Removed non-ipsec entries and added note to introduction on these - Removed no longer used RFC-4595 reference I think this document is now ready for a call for adoption. Paul From nobody Fri Sep 2 01:55:08 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB19C12D7B1 for ; Fri, 2 Sep 2016 01:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_zIf6pn2ajb for ; Fri, 2 Sep 2016 01:55:05 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB8312D79D for ; Fri, 2 Sep 2016 01:55:05 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id c133so19117119wmd.1 for ; Fri, 02 Sep 2016 01:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=jKuzh9iFi+bsBnLGvV4H3hYsijmGmMU/Z45uBcLlQBo=; b=wLXwCIs0CYej/XpmB7LsGWHf2dClo8lwYASy5FmwksjyivtURdQoA/nn+LtxYBGhrT CTbJ6piZ5YynReO4P5bpg6gXaCg6vMW0xiY0rOQXNpZesSbXA6sQYd8+TOi/oyg0NGxD TOtko2WFhfJKoQL3F9R3nrz3AwNORSJlcYecugYYIGguAFW0mFT3M6QA/UaOD5QRCCeK WWiWQ7w04rXtz2ruG9PI6iPfDQlV30o6aulUQ+IUBDg+ETdxcEpyLIyZIBnCoxXHt2/a /fzgGsEIws/NjIs7jbO1LF2568rCLI7FyPT1ahIrOMfgf1vsv24teuuQr5ZVZEnqKXXH tITg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=jKuzh9iFi+bsBnLGvV4H3hYsijmGmMU/Z45uBcLlQBo=; b=mkURASylgvDSU2hu/2/zE4DPsr/+UvSHUUEOLfeRoW5Zzn4GT0K2QN7WNrSGZoADok UITBnREkTf55GR2J1u1HL1k0nOhn/wbyp8u4EOzLtBFRmT6ulsk1xkTLJwEqCAjefym4 20xn2NXzXk/ciSiWSQILlXffMruVR/V9JvhXQcSy6wdGKSpLFU1OS06u7g/7o2jpMeZc XRF4IcaGMTiuxpgySP1KsauXtN0CaGXsCM5E0XiOabW/l51AlE7hV+5lIkCAQ1jAMFnJ AGcBTUsPbjYsl5eDlAFSpGG2gXeoAqEheGoCpLHKmM5h2Bk84ID8pojWfe/uoRqTAdRx IkcA== X-Gm-Message-State: AE9vXwO8NnT3pbcTPx6mxWydqQh0pLhgMrkLtY6XBMlcA1iXR8bcqZKASfxeG2I4Mkjvqw== X-Received: by 10.28.18.11 with SMTP id 11mr2024936wms.11.1472806503344; Fri, 02 Sep 2016 01:55:03 -0700 (PDT) Received: from [10.0.0.1] (bzq-109-67-209-47.red.bezeqint.net. [109.67.209.47]) by smtp.gmail.com with ESMTPSA id a2sm9353226wjg.46.2016.09.02.01.55.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Sep 2016 01:55:02 -0700 (PDT) To: Paul Wouters , "ipsec@ietf.org WG" References: From: Yaron Sheffer Message-ID: <860ec25d-033d-b12d-541c-423caf3803d7@gmail.com> Date: Fri, 2 Sep 2016 11:55:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 08:55:07 -0000 Can we make all the compression algorithms SHOULD NOT instead of MAY? TLS got rid of compression altogether, there are numerous attacks on compressed traffic, and even the document states that these algorithms are not widely implemented. Thanks, Yaron On 02/09/16 05:49, Paul Wouters wrote: > > I just published draft-mglt-ipsecme-rfc7321bis-03 (well and -02) > > (ietf announcement of these seems delayed?) > > https://tools.ietf.org/html/draft-mglt-ipsecme-rfc7321bis-03 > > The changes are: > > - Update 256-bit key sizes to MUST (except IoT) - similar to 4307bis > - Add Security Section from RFC7321 > - Removed MAY algorithms (RC5, CAST, IDEA, ENCR_AES_CCM_16) > - Added note on ENCR_BLOWFISH > - Removed notes on removed MAY list entries (CCM & GCM flavours, GMAC, > CMAC)) > - Removed non-ipsec entries and added note to introduction on these > - Removed no longer used RFC-4595 reference > > I think this document is now ready for a call for adoption. > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Sep 2 04:18:36 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC7C12D189 for ; Fri, 2 Sep 2016 04:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7ypCoCHrdHx for ; Fri, 2 Sep 2016 04:18:32 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A5CE12B037 for ; Fri, 2 Sep 2016 04:18:32 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id p41so62710877lfi.1 for ; Fri, 02 Sep 2016 04:18:32 -0700 (PDT) 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-transfer-encoding; bh=aGbA6NPoFxxQoGVEga/apu6ci+l6VRP9/nCjrQinPCo=; b=MKnlWaw/BvKgLuwY9UjODkbJMbSPMvf1WJ2P/KS+5GTBSBRkB2YMTRl25vSE2bo+nm 2zO4zTGen2+35gxaSI9TTbS2l81S3VL1Umf8zTEOdGcLq4ek4Yjz2t7+SiN9QhJ3OC7j /TILPIxX0URTMFMUcTc/6UpiXfm3KP6N6LWRV/Ra2YV84FhmAgKb61OdFX42+N5eOHR9 OtYDuVAy5/IwfkWeME/uEQcPmaLjT5PCmYaTLJ3lL0eVGLRMUoajdQuZ49YwEPIo+3gU hgJ5l1AXknogjNO2/gXnfF1qM450uH6K0wRYyssV2St4bRUqmEUEjqjt00+dUbBST9zI eP0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version:content-transfer-encoding; bh=aGbA6NPoFxxQoGVEga/apu6ci+l6VRP9/nCjrQinPCo=; b=HWSemA0IQEoTCgkJqwL014FfQtsQG+V0P2X/bfn08vLDvnsRzQS3gTaJk/IQRWzIQv an9+Xyn5gzHep/7VIYvrV5yTEmlkb826M45US5IsdM6V9kHe9TetBvdEtXKJzJ2Jx40l GcQjbYqNmoueX0QdAs0DvUsjz4wNnj0d7AcTxs1qNIfLcePh+0JP9BtaHbamoHZihlHy dO6T7mZRYS4gsNURKu1eDrdHvDOaYOviQJ0MbbfQnIpVsBDZoDXIlWbF96ws1u/S85zR E6RtlIEtgmvLR3vDg5ufh8G4Lqp45wR62ftb8zP6b6Id1k0Dkt2A9R4Set/VgorUUzTi tnYQ== X-Gm-Message-State: AE9vXwO7CyHwPc0I2bAyCwBJmr4mz+2R8tyoyg45DxHpTBP5UYgLLKGXLACrD9O1ZQrmGg== X-Received: by 10.25.78.83 with SMTP id c80mr1804426lfb.174.1472815110287; Fri, 02 Sep 2016 04:18:30 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id s82sm2161165lja.14.2016.09.02.04.18.29 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Fri, 02 Sep 2016 04:18:29 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" , , "Yaron Sheffer" References: <860ec25d-033d-b12d-541c-423caf3803d7@gmail.com> Date: Fri, 2 Sep 2016 14:18:09 +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: Subject: Re: [IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 11:18:34 -0000 Hi Yaron, > Can we make all the compression algorithms SHOULD NOT instead of MAY? > TLS got rid of compression altogether, there are numerous attacks on > compressed traffic, and even the document states that these algorithms > are not widely implemented. What attacks do you mean? Those that I'm aware of (CRIME, BREACH) are specific to HTTP and cannot be directly used with ESP (ESP has a mandatory padding and an optional TFC padding that make those attacks impractical). Are there any new or more applicable attacks that I've missed? I see no reason to downgrade compression to SHOULD NOT unless we have an indication that it is really dangerous in the context of ESP. Regards, Valery. > Thanks, > Yaron > > On 02/09/16 05:49, Paul Wouters wrote: >> >> I just published draft-mglt-ipsecme-rfc7321bis-03 (well and -02) >> >> (ietf announcement of these seems delayed?) >> >> https://tools.ietf.org/html/draft-mglt-ipsecme-rfc7321bis-03 >> >> The changes are: >> >> - Update 256-bit key sizes to MUST (except IoT) - similar to 4307bis >> - Add Security Section from RFC7321 >> - Removed MAY algorithms (RC5, CAST, IDEA, ENCR_AES_CCM_16) >> - Added note on ENCR_BLOWFISH >> - Removed notes on removed MAY list entries (CCM & GCM flavours, GMAC, >> CMAC)) >> - Removed non-ipsec entries and added note to introduction on these >> - Removed no longer used RFC-4595 reference >> >> I think this document is now ready for a call for adoption. >> >> Paul >> >> _______________________________________________ >> 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 Sep 2 04:25:25 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79F212D112 for ; Fri, 2 Sep 2016 04:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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.548] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gejCazJrG8cY for ; Fri, 2 Sep 2016 04:25:23 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2133612D0C9 for ; Fri, 2 Sep 2016 04:25:23 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sQcHP0NtzzJt5; Fri, 2 Sep 2016 13:25:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1472815521; bh=O4aPtkJVeW0CnE9zUiIqoOkYCq0Jku5AF1kPKWTBUWI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=dV+5BGMf2FzMkv1L3FknOMlbeQHKBm99llsHP01eZ+O5Db2YHZNwVLYae9lk0p74q gBhyUezMyc97atAxM3GCKvfxzLgRTL0WzK4uj0R7gOAZuWVhk68mP6Bn5tGr3UGp3Z q67HFUbheX1BW+iBeQaH4uJ5MqaQKHXGIuJNlAYo= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ToIoTQ3lUQeI; Fri, 2 Sep 2016 13:25:20 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 2 Sep 2016 13:25:20 +0200 (CEST) Received: from [193.111.228.71] (unknown [193.111.228.71]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 47D302ED945; Fri, 2 Sep 2016 07:25:19 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 47D302ED945 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (13G36) In-Reply-To: <860ec25d-033d-b12d-541c-423caf3803d7@gmail.com> Date: Fri, 2 Sep 2016 07:25:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <16FF5F35-21F7-4789-84CF-5BB99645B13B@nohats.ca> References: <860ec25d-033d-b12d-541c-423caf3803d7@gmail.com> To: Yaron Sheffer Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 11:25:25 -0000 > On Sep 2, 2016, at 4:55 AM, Yaron Sheffer wrote: >=20 > Can we make all the compression algorithms SHOULD NOT instead of MAY? I would love too (to remove the added complexity) but it is really out of sc= ope for the algorithm update document. Paul= From nobody Fri Sep 2 05:40:42 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEF712B024 for ; Fri, 2 Sep 2016 05:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRnxxhuEDnLn for ; Fri, 2 Sep 2016 05:40:38 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13FA312B011 for ; Fri, 2 Sep 2016 05:30:46 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id v143so28854331wmv.0 for ; Fri, 02 Sep 2016 05:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=5ebXbjQy/19WHTkCQ1t607nI1gNQZdaUx3VNGeJC390=; b=raY7+uakKWu+K8IUBMahlQftVqlxlsK2S1Y2pRoLdRLOYb0SxPXSyK6PBLf3wMbN1L hOIXmty2v1qRXBGt5kyeDRL4ZWPozX+4JnYdCASnOcL08Du/zCN85QAO2gj1V9HPVgkl qTzSLQHcdj1aEsf9MZpLU+jIzb9R9dUJXy82ld5VVtQBdFzi84p32xT7g1pc0I9Clntg tjc1LUwdnIgZn/ux/+dHxGWMkKpX6u4zcIXxryvhBT+/rkc/dlP3KoQKzrWa4ckZgM2c E9OTbEuKzLQ3sZ7hG+bzKjZ4u7OYitb1GHC4YiyDDXkWySuSh90Ut1M5tvI9wtuhyOaa FaLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=5ebXbjQy/19WHTkCQ1t607nI1gNQZdaUx3VNGeJC390=; b=ITSQqNEIqZxQgmxuM5HQyepGKnW+lHmXyugiCm/U7xlAi8SQNRGD97Joo7tu4hv/dZ W7+M0G5mJ1RNo28Foiqi32Fj2XXjB/yiT0GwrFsXDTpjmvdXE/+d5LsQJdcEo7IiFHzW BUPa2gQQEuEJGyhVnQRAZFt/qgOgzYMpcv6Y97bkRohbq1pTh1s8FDdUeDEGowAmpkzh mpgoC/fUngQwxo64IWWUjW1yJBOHd6DGICjvBYhyvfxyajL2KikozCS70/LepSZ71FXq ORFCVPmy4vKgBjoG3So2d8xxaUslOat61T2S8CNiugSrol1OtebmUHgPSD3SpaaLJsf+ lctw== X-Gm-Message-State: AE9vXwP/ayjqTofvjCno4rAST+HgRH1s3+/PjsJIllCFaSCF1EkzfabJa/sFizRNepUR0g== X-Received: by 10.28.163.199 with SMTP id m190mr2905430wme.5.1472819443738; Fri, 02 Sep 2016 05:30:43 -0700 (PDT) Received: from [10.0.0.1] (bzq-109-67-209-47.red.bezeqint.net. [109.67.209.47]) by smtp.gmail.com with ESMTPSA id z18sm3400672wmz.6.2016.09.02.05.30.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Sep 2016 05:30:42 -0700 (PDT) To: Paul Wouters References: <860ec25d-033d-b12d-541c-423caf3803d7@gmail.com> <16FF5F35-21F7-4789-84CF-5BB99645B13B@nohats.ca> From: Yaron Sheffer Message-ID: <7e5bc7f3-9fe5-aa54-1d2f-be7da324250d@gmail.com> Date: Fri, 2 Sep 2016 15:30:40 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <16FF5F35-21F7-4789-84CF-5BB99645B13B@nohats.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 12:40:41 -0000 Valery, here's what I could find: * https://www.cs.jhu.edu/~cwright/oakland08.pdf * http://www.techeye.net/security/skypes-encryption-destroyed-by-phonemes And another attack was published recently, but I cannot find it. So this is for voice, and the better known TLS attack are for HTTP. Paul, why is this out of scope? Thanks, Yaron On 02/09/16 14:25, Paul Wouters wrote: > > >> On Sep 2, 2016, at 4:55 AM, Yaron Sheffer wrote: >> >> Can we make all the compression algorithms SHOULD NOT instead of MAY? > > I would love too (to remove the added complexity) but it is really out of scope for the algorithm update document. > > Paul > From nobody Fri Sep 2 06:06:56 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A165512D824 for ; Fri, 2 Sep 2016 06:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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.548] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJb-M24r2cld for ; Fri, 2 Sep 2016 06:06:53 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EFED12D805 for ; Fri, 2 Sep 2016 06:06:53 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sQfXX0Jh0zJt7; Fri, 2 Sep 2016 15:06:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1472821612; bh=Dk39H2O5ZwZvFGs4VSkum+iKN26kdiIuh591D6TlwTU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=M6+RVXhBVkltzuvYcDOjI5k7LU73JgMo/WFrSTqUsSUgAcY4ONFlQsnDY1DLCQr16 2m3TgG2mLsnKNtKj/DlHy3OfkRZrNguVvVEFMcp2WdDTz8OSBW2SnjSc3YbbVdBQJ0 qShXf/Lwpxf2aUHkRePZFmHfh/vZWKcj6sC1ZLg4= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id M01j7Tl41MIb; Fri, 2 Sep 2016 15:06:50 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 2 Sep 2016 15:06:50 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D73B92ED945; Fri, 2 Sep 2016 09:06:49 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca D73B92ED945 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CDD93410929E; Fri, 2 Sep 2016 09:06:49 -0400 (EDT) Date: Fri, 2 Sep 2016 09:06:49 -0400 (EDT) From: Paul Wouters To: Yaron Sheffer In-Reply-To: <7e5bc7f3-9fe5-aa54-1d2f-be7da324250d@gmail.com> Message-ID: References: <860ec25d-033d-b12d-541c-423caf3803d7@gmail.com> <16FF5F35-21F7-4789-84CF-5BB99645B13B@nohats.ca> <7e5bc7f3-9fe5-aa54-1d2f-be7da324250d@gmail.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 13:06:54 -0000 On Fri, 2 Sep 2016, Yaron Sheffer wrote: > Paul, why is this out of scope? Because we want to only update the algorithms, and not change the core 7296 RFC. It's one thing to promote or demote certain compression schemes. It is quite a difference to obsolete the compression type alltogether. And again, just for the record, I'm all for it. But I think perhaps a seperate document that just obsoletes all compression would be better. (Also AH :) Paul From nobody Fri Sep 2 06:32:47 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841F712D88D for ; Fri, 2 Sep 2016 06:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YAQkJOlLZYm for ; Fri, 2 Sep 2016 06:32:44 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 859D912D88A for ; Fri, 2 Sep 2016 06:32:43 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id p41so65272335lfi.1 for ; Fri, 02 Sep 2016 06:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=hzgP1tSURWSMyPmsPt4kn8YNPEz8yuQ8hrNBItI//S4=; b=OR6HRANXJnpUzNfHU0iwy8zCSHLCeq/sv92Qo2itAZTGP/LF1P95Ypi3HJiDLd7M9A HhJ6z/x/2JiBaEbK3d+2DCvMaiZy6c05y1YV2FgxQiqtgSjqosFF9jWjh+Bcjjdv3+JT xQPr7n33A9Foj2BmZLAGAiZr+wMby950EceLvVG5b9u7XSKDom3oJjUhLNHWWt87Ax/k 1gwBr+67b3IU4DBofuyAHDDtGrTI4Ls566tdFxL4IOE+KNibsAP5D/cYAV9OkExl7QIP q2ZkUtwtnH0eGw0uTq4aCQQaOVxpeSsA/23HoWtCdznbNStBeyI68aR/W7dgFb8xtS1D L/ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=hzgP1tSURWSMyPmsPt4kn8YNPEz8yuQ8hrNBItI//S4=; b=jielV1Vfje7zV7PFbnYFhRtN4d+9TspShDRrntWpME/11QiX/AKJXWlYvs6B22umwp k3FOgwE/3rPxLDImUEyfw3F8CfUXr943X9Ho/12PZHhbNoEe7bhiA6uWQuO/EduFf/Nz FjpIRMwL+9tetlXqxTOPoECWiqmt8BrzSj/nC4v/Na/U8ajs8n//8tdOY8ecr8+wtRYe VntKqYSZnhkfNmvN/t8YU/vvHGiabZEI/pQ+hD/92XIwnAMmoV245/OwycRSS3ymbZCZ LmqBOM3j/KFw0AdE6+Beq4Z1ajCYhTknEO76+fCU+eYtJer+nDmtnIQNoQrPWJGWgsbl PtWQ== X-Gm-Message-State: AE9vXwPXwbDN0RS4Xjw1dCNdhtaiR1ZejJoADYNAHLV4MHoLTAbh9B0Lyi/FABJH77/4CA== X-Received: by 10.46.1.85 with SMTP id 82mr639148ljb.8.1472823161484; Fri, 02 Sep 2016 06:32:41 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id m123sm2224293lfm.7.2016.09.02.06.32.40 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Fri, 02 Sep 2016 06:32:40 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" , "Yaron Sheffer" References: <860ec25d-033d-b12d-541c-423caf3803d7@gmail.com> <16FF5F35-21F7-4789-84CF-5BB99645B13B@nohats.ca> <7e5bc7f3-9fe5-aa54-1d2f-be7da324250d@gmail.com> Date: Fri, 2 Sep 2016 16:32:20 +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: Cc: ipsec@ietf.org Subject: Re: [IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 13:32:46 -0000 Yaron, I don't think these attacks are relevant to ESP compression. As far as I understand, they rely on statistical analysis of the frame lengthes when phonems are encoded with a lossy compression algorithm. I don't see how it affects losless compression used in ESP. Regards, Valery. > Valery, here's what I could find: > > * https://www.cs.jhu.edu/~cwright/oakland08.pdf > * http://www.techeye.net/security/skypes-encryption-destroyed-by-phonemes > > And another attack was published recently, but I cannot find it. > > So this is for voice, and the better known TLS attack are for HTTP. From nobody Fri Sep 2 06:42:09 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915C212D89B; Fri, 2 Sep 2016 06:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXwPuOaY9MVO; Fri, 2 Sep 2016 06:42:01 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B3712D87D; Fri, 2 Sep 2016 06:41:59 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u82Dft0L012091 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Sep 2016 16:41:55 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u82Dfr35013948; Fri, 2 Sep 2016 16:41:53 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22473.33185.527507.419009@fireball.acr.fi> Date: Fri, 2 Sep 2016 16:41:53 +0300 From: Tero Kivinen To: kathleen.moriarty.ietf@gmail.com In-Reply-To: <52A62106-3A93-4511-9FAD-4641BDDFA4CA@gmail.com> References: <147269503033.31834.10513562338482321120.idtracker@ietfa.amsl.com> <52A62106-3A93-4511-9FAD-4641BDDFA4CA@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 23 min X-Total-Time: 23 min Archived-At: Cc: ipsec@ietf.org, Ben Campbell , ipsecme-chairs@ietf.org, The IESG Subject: Re: [IPsec] Ben Campbell's No Objection on charter-ietf-ipsecme-10-01: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 13:42:02 -0000 kathleen.moriarty.ietf@gmail.com writes: > Could you respond on the timeline and if you think it's reasonable > and why or if it should be changed. Sure. Out of the nine documents to be published, there is two which are already going out from the WG, i.e., which are already submitted for publication (DDoS and curve25519). Two more are almost ready (4307bis and 7321bis), and those are updating the MTI requirements, thus there is not that much of protocol work, we just need to agree what is suitable level for each algorithm. This means that four of the documents should be out from the WG hands before the next IETF, and hopefully published as RFC on first half of 2017... Then there is EdDSA which is mostly waiting for the curdle-pkix to agree on the OIDS to be used for the EdDSA, and then it should be ready soon after that is done (it is 2 page document just saying we do what draft-irtf-cfrg-eddsa and draft-ietf-curdle-pkix do). For the rest of the items, we have quite stable drafts for three of them (tcp-encp, split-dns, and implicit IV), so after we get those first drafts out, we should get them done during the winter. Only thing that still requires more work is the quantum resistant version of the IKEv2, and even for that, I think we already have the idea how it will be done, and it should not take too long. Also I would assume that during 2017 we most likely will get some new work items that will start working on, thus we will most likely want to do recharter by the end of 2017 anyways. And if there is nothing new to be done, and we have only 1-2 items left, we can continue working them without WG if needed. Year ago (IETF 93, July 2015) we had started charter dicussion last time, i.e., during the meeting we discussed whether we should close down the WG, or recharter and continue. Then we decided to keep the WG, and recharter, but the recharter discussion took some time, and as we did not meet in Yokohama IETF 94, the discussion on charter started on the IETF 95 in Buenos Aires, and finalized during the IETF 96 in Berlin. -- kivinen@iki.fi From nobody Fri Sep 2 06:56:40 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F80412D8AB for ; Fri, 2 Sep 2016 06:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzVmvOOzeqNV for ; Fri, 2 Sep 2016 06:56:38 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAFF412D1D8 for ; Fri, 2 Sep 2016 06:56:37 -0700 (PDT) Received: (qmail 11569 invoked from network); 2 Sep 2016 15:56:35 +0200 Received: from p5dec2984.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.41.132) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 2 Sep 2016 15:56:34 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <22473.33185.527507.419009@fireball.acr.fi> Date: Fri, 2 Sep 2016 15:54:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <424A6EE6-7EC4-4503-99E5-AF482C799478@kuehlewind.net> References: <147269503033.31834.10513562338482321120.idtracker@ietfa.amsl.com> <52A62106-3A93-4511-9FAD-4641BDDFA4CA@gmail.com> <22473.33185.527507.419009@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ipsec@ietf.org, Ben Campbell , kathleen.moriarty.ietf@gmail.com, ipsecme-chairs@ietf.org, The IESG Subject: Re: [IPsec] Ben Campbell's No Objection on charter-ietf-ipsecme-10-01: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 13:56:39 -0000 Hi all, two comments: > Am 02.09.2016 um 15:41 schrieb Tero Kivinen : >=20 > Also I would assume that during 2017 we most likely will get some new > work items that will start working on, thus we will most likely want > to do recharter by the end of 2017 anyways. If that=E2=80=99s the case I would recommend to remove the deadline from = the charter. Please note that if you end up without new work you can = always ask your AD to close the group (even without this deadline in the = charter). > And if there is nothing > new to be done, and we have only 1-2 items left, we can continue > working them without WG if needed. That=E2=80=99s usually not a good ideas. If you don=E2=80=99t have a wg = all docs need to be AD sponsored. If you have a wg you can just finish = your doc, ask for reviews on the mailing, and run an WGLC to ensure = there is enough review. You don=E2=80=99t have to have meetings or what = ever. I don=E2=80=99t see a reason to close a wg before the work is done = (if there is enough energy to finish the work). Mirja From nobody Fri Sep 2 09:36:14 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA0812D548; Fri, 2 Sep 2016 09:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hEtsH62KG5G; Fri, 2 Sep 2016 09:36:06 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B737012D08D; Fri, 2 Sep 2016 09:36:06 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id v189so27909296vkv.1; Fri, 02 Sep 2016 09:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=VYnP283Z/KCzBpz9ycrPzX0EjR6/tKanaB4oK6lJDIE=; b=zxrlI8rD2f0bP4I2X1hdbyNr931JPzkG574J11dxYBLtaD8lQ73EgKBT44n+Xtz+rH YkY0PWZaYmDY6gH/DM/DIFXlC/jHvyImAC5tPimpUuqmEnzfHXMu/lc3P1BHBCkQ4gRY WzTAc1Mt2hMGf11gqZKurZj5TwSm8dC+JzC+UszGwQXHiZEFWEI3/WIHM4EIhUkBr5nb brImW5RrPrfNkqcaYGhRIvI5eRr6k4S9bYlkzSmYNi5amvTKPQh+JrWdYRC//4kKk8ia R7SbNdZWkTqhcz24pWJeZjlOqQUzY0a5qg/51OzOCmot6tf4ugQW7D2ymQeTzpp6tKwo rcuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=VYnP283Z/KCzBpz9ycrPzX0EjR6/tKanaB4oK6lJDIE=; b=UVGAAYsiWidpPoVc1IBTRnRyoxVK57KyG2KtcehRASK7oo6Hha96c6kppcZr4CqubZ 1ntQWWa+u11Np1zlEAtB4CulKMh+3xi/qthS54OZYBq8uLkp8TkBO5Vyi+iNggJpJS2N +1ukHjnmXCzc0lnK8NoYeI7r2W+hmBpnSozLqpq8odXx5AadCf6yIRstD3d+en49d108 Cdf08bihkziba15a8ZXLfHMxKHs14m7i1SpNmH6ALH9h4UvJYwwMibuGqtiwzw1hQ1Z7 pJ4/d28ASv3EeOMOfqlzPi3pJUsuK3MPx1eRIcyFf4nrsBKb/Z+0qk2yD0BthEIHr1D2 3nig== X-Gm-Message-State: AE9vXwPxREa6rMEI+xfedPIqSu5TdB0X1egFpx0ZULuA/ALr/KBD8mjivBYdGgeNyKdTD4gmYhGdESUYZpAtaQ== X-Received: by 10.31.80.135 with SMTP id e129mr13883489vkb.151.1472834165852; Fri, 02 Sep 2016 09:36:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.226 with HTTP; Fri, 2 Sep 2016 09:36:04 -0700 (PDT) In-Reply-To: <424A6EE6-7EC4-4503-99E5-AF482C799478@kuehlewind.net> References: <147269503033.31834.10513562338482321120.idtracker@ietfa.amsl.com> <52A62106-3A93-4511-9FAD-4641BDDFA4CA@gmail.com> <22473.33185.527507.419009@fireball.acr.fi> <424A6EE6-7EC4-4503-99E5-AF482C799478@kuehlewind.net> From: Kathleen Moriarty Date: Fri, 2 Sep 2016 12:36:04 -0400 Message-ID: To: "Mirja Kuehlewind (IETF)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "ipsec@ietf.org" , Ben Campbell , ipsecme-chairs@ietf.org, The IESG , Tero Kivinen Subject: Re: [IPsec] Ben Campbell's No Objection on charter-ietf-ipsecme-10-01: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 16:36:08 -0000 Hello, On Fri, Sep 2, 2016 at 9:54 AM, Mirja Kuehlewind (IETF) wrote: > Hi all, > > two comments: > >> Am 02.09.2016 um 15:41 schrieb Tero Kivinen : >> >> Also I would assume that during 2017 we most likely will get some new >> work items that will start working on, thus we will most likely want >> to do recharter by the end of 2017 anyways. > > If that=E2=80=99s the case I would recommend to remove the deadline from = the charter. Please note that if you end up without new work you can always= ask your AD to close the group (even without this deadline in the charter)= . I don't see why this is such an issue, including a deadline in the charter. It hasn't been a problem for the past 2.5 year (and for the AD for this group before). I'm fine with a deadline remaining in the charter. > >> And if there is nothing >> new to be done, and we have only 1-2 items left, we can continue >> working them without WG if needed. > > That=E2=80=99s usually not a good ideas. If you don=E2=80=99t have a wg a= ll docs need to be AD sponsored. If you have a wg you can just finish your = doc, ask for reviews on the mailing, and run an WGLC to ensure there is eno= ugh review. You don=E2=80=99t have to have meetings or what ever. I don=E2= =80=99t see a reason to close a wg before the work is done (if there is eno= ugh energy to finish the work). I can manage this with the WG. Thank you. > > Mirja > --=20 Best regards, Kathleen From nobody Fri Sep 2 09:59:35 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51EF12D0FE for ; Fri, 2 Sep 2016 09:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k2lm6JTL70r for ; Fri, 2 Sep 2016 09:59:32 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1949D12B01E for ; Fri, 2 Sep 2016 09:59:32 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id c133so38626763wmd.1 for ; Fri, 02 Sep 2016 09:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=lxdLWTAtDSOB+s/SVVc3zRf1ETacVqrRL2Gcql4NW3Q=; b=MglrbW9F8pKBPqXNuUQv0pw1ck3e+fHr8S6w6X62yXWyA8lb/5Q9TWtxQfLou4glui ZPZUQTxCrBJeodpVw5jAsVOmy2jT10+3pljfkOe/hcMTdpyI+xYIcS0ddHILj/pmFVh0 KAJ2IrQq0wO8BD4xYE+Yg0DHbkxvQI9Agqur/oHOsdVk4F9bf1vlQVKArRg+1TvTB3U/ PWs4xrl8mD35HuyVVIwfWvjumTHXdH3e4Z5eIKKX/tCL+JnabxVRr45ocLFltdP6UPGB wexKOwKNSPYD3tGb4Npw10toT5qDqu6GF96lnprhgjykD9IWQr9b8L4tAyY/HkadZd7P Aadg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=lxdLWTAtDSOB+s/SVVc3zRf1ETacVqrRL2Gcql4NW3Q=; b=bRxR1nK/WVUcXYIJKSx5mQPgx/Q/c4XqYwzuVeBA4msIroJ2o3TFjri9K5XTYou6tW QEZqA5g2sZtaAscRyKKeKFP53lP7D8HS53yNRwGE48uF5evj/kf8ri8zduOi1lzbZnF1 nOn7feuT2aLoOSEcJRMoKRWCsiwhVBNSgW7KVHmAzPdtNfscwHhbf1BqVMnULNrjA0zm 3UxJFHj6A0jrHJ6jxTdxABalQC6sJ9V/UArP1pzXYkqIqFe6S82g6vNO/l9OnllwcxFq HkZ7Vwi1iR1/LsMckzDAfzXxPlDaOsvlHjEPI13psUIosaQG7cZ7P/QSJoxKXccrVAI4 Rk/Q== X-Gm-Message-State: AE9vXwOwJMx8dgbUunV/rXGk4jrGvmC4XYxXIhKd/kH+VtbbPXw0YCTeMm9ExiDQO2MyQw== X-Received: by 10.28.56.195 with SMTP id f186mr4066145wma.59.1472835570338; Fri, 02 Sep 2016 09:59:30 -0700 (PDT) Received: from [10.0.0.1] (bzq-109-67-209-47.red.bezeqint.net. [109.67.209.47]) by smtp.gmail.com with ESMTPSA id r4sm11329805wjs.13.2016.09.02.09.59.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Sep 2016 09:59:29 -0700 (PDT) To: Valery Smyslov , Paul Wouters References: <860ec25d-033d-b12d-541c-423caf3803d7@gmail.com> <16FF5F35-21F7-4789-84CF-5BB99645B13B@nohats.ca> <7e5bc7f3-9fe5-aa54-1d2f-be7da324250d@gmail.com> From: Yaron Sheffer Message-ID: Date: Fri, 2 Sep 2016 19:59:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 16:59:34 -0000 Hi Valery, Yes, these are lossy algorithms, but the TLS/HTTP attacks are all with lossless algorithms. And as far as I know, they are applicable to any situation where here is an attacker that can force traffic on the wire, mixed with other, non-attacker controlled traffic. So IMO they are not restricted to just HTTP. Thanks, Yaron On 02/09/16 16:32, Valery Smyslov wrote: > Yaron, > I don't think these attacks are relevant to ESP compression. > As far as I understand, they rely on statistical analysis of the frame > lengthes when phonems are encoded with a lossy compression algorithm. I > don't see how it affects losless compression used in ESP. > > Regards, > Valery. > > >> Valery, here's what I could find: >> >> * https://www.cs.jhu.edu/~cwright/oakland08.pdf >> * http://www.techeye.net/security/skypes-encryption-destroyed-by-phonemes >> >> And another attack was published recently, but I cannot find it. >> >> So this is for voice, and the better known TLS attack are for HTTP. > > > > > > From nobody Fri Sep 2 10:20:40 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7554412B058 for ; Fri, 2 Sep 2016 10:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKpwbalClmL0 for ; Fri, 2 Sep 2016 10:20:32 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA22612D6A1 for ; Fri, 2 Sep 2016 10:20:31 -0700 (PDT) Received: (qmail 19490 invoked from network); 2 Sep 2016 19:20:29 +0200 Received: from p5dec2984.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.41.132) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 2 Sep 2016 19:20:29 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Fri, 2 Sep 2016 19:20:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147269503033.31834.10513562338482321120.idtracker@ietfa.amsl.com> <52A62106-3A93-4511-9FAD-4641BDDFA4CA@gmail.com> <22473.33185.527507.419009@fireball.acr.fi> <424A6EE6-7EC4-4503-99E5-AF482C799478@kuehlewind.net> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ipsec@ietf.org" , Ben Campbell , ipsecme-chairs@ietf.org, The IESG , Tero Kivinen Subject: Re: [IPsec] Ben Campbell's No Objection on charter-ietf-ipsecme-10-01: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 17:20:34 -0000 That=E2=80=99s fine. It=E2=80=99s just my opinion. But as responsible AD = you can of course handle this as you like. Mirja > Am 02.09.2016 um 18:36 schrieb Kathleen Moriarty = : >=20 > Hello, >=20 > On Fri, Sep 2, 2016 at 9:54 AM, Mirja Kuehlewind (IETF) > wrote: >> Hi all, >>=20 >> two comments: >>=20 >>> Am 02.09.2016 um 15:41 schrieb Tero Kivinen : >>>=20 >>> Also I would assume that during 2017 we most likely will get some = new >>> work items that will start working on, thus we will most likely want >>> to do recharter by the end of 2017 anyways. >>=20 >> If that=E2=80=99s the case I would recommend to remove the deadline = from the charter. Please note that if you end up without new work you = can always ask your AD to close the group (even without this deadline in = the charter). >=20 > I don't see why this is such an issue, including a deadline in the > charter. It hasn't been a problem for the past 2.5 year (and for the > AD for this group before). >=20 > I'm fine with a deadline remaining in the charter. >=20 >>=20 >>> And if there is nothing >>> new to be done, and we have only 1-2 items left, we can continue >>> working them without WG if needed. >>=20 >> That=E2=80=99s usually not a good ideas. If you don=E2=80=99t have a = wg all docs need to be AD sponsored. If you have a wg you can just = finish your doc, ask for reviews on the mailing, and run an WGLC to = ensure there is enough review. You don=E2=80=99t have to have meetings = or what ever. I don=E2=80=99t see a reason to close a wg before the work = is done (if there is enough energy to finish the work). >=20 > I can manage this with the WG. >=20 > Thank you. >=20 >>=20 >> Mirja >>=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen From nobody Fri Sep 2 11:01:25 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5714112B01C; Fri, 2 Sep 2016 11:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqqQ24utVupj; Fri, 2 Sep 2016 11:01:16 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C605512D1BC; Fri, 2 Sep 2016 11:01:15 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id j189so20186275vkc.2; Fri, 02 Sep 2016 11:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/DU/nwkGL9kcM8/Bt7znMovaUpm17T64jZclcwptZww=; b=kjqFtRakaj7JSheJwgQui/7Y1FnpKqh5YMwIGRSJZ9zEcDziqiqYVvbd9JF/Zwn0nl cZPZBoYGcL4eNg91MxyD66fHiMDaPfJQvxPr1S2S6p8EzHVuobLF23MnWgdQdr4g3G+z qzY3CbV/fzfeJSLiYci97fMO44tUUfyk0lRLGdeGEb1PWJNSzd+gwWAl4ZLMGM4XnXTB eg6aA2Km1PfM/SbzrjozrvTsc6GdzHINz3xxW5e3SH2g4I+p7Fva1OzrVKmGMAbhfo9+ 97bEt/ODHLftiFd6vKeiZiyt9Vy5bDzYjuT6HlWQPftz9qOQt76ZD45jzAe4PdcuIMQV lDnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/DU/nwkGL9kcM8/Bt7znMovaUpm17T64jZclcwptZww=; b=fvyTm8fmE69azoFhwNgaYiMuZqm4y7opmNUZD4U9mPWkMEP3R0lAg16EYy8J2arCKZ /Af3Vb5rHipASuGLYVqib6xEOd+skyRLgRVIecryom+XrYxRwQjvskmjIIUs1NWBuX2H AE2vpEd6Jibw8S9DfiOwaq+6AJO4Vwg2h0bhnZAM0gTeafzxFuBvhfkTMTANtFuId/ob /n8G6iI5jfg05lC1mN6AzsrRagVcMUd9THT3Gw/lx46aHboLnZD8Fvpazw7vKX9tBzHA tzBHR7PAIgOthSveKak7oG+Eh5fzoLFs3uWm0dJoQuKbSN3ISuIXEuwiv3D+dyGkoxKi 3dgw== X-Gm-Message-State: AE9vXwPWpW0HMzoOBDZ8O8ROo8FvGCW9F04vC7Qhv5JGFnFFrVdIT4J5SYuyqHWqKAEgpX/kQyXV8XEqq2u15A== X-Received: by 10.31.129.11 with SMTP id c11mr14122935vkd.25.1472839274890; Fri, 02 Sep 2016 11:01:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.226 with HTTP; Fri, 2 Sep 2016 11:01:14 -0700 (PDT) In-Reply-To: References: <147269503033.31834.10513562338482321120.idtracker@ietfa.amsl.com> <52A62106-3A93-4511-9FAD-4641BDDFA4CA@gmail.com> <22473.33185.527507.419009@fireball.acr.fi> <424A6EE6-7EC4-4503-99E5-AF482C799478@kuehlewind.net> From: Kathleen Moriarty Date: Fri, 2 Sep 2016 14:01:14 -0400 Message-ID: To: "Mirja Kuehlewind (IETF)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "ipsec@ietf.org" , Ben Campbell , ipsecme-chairs@ietf.org, The IESG , Tero Kivinen Subject: Re: [IPsec] Ben Campbell's No Objection on charter-ietf-ipsecme-10-01: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 18:01:17 -0000 On Fri, Sep 2, 2016 at 1:20 PM, Mirja Kuehlewind (IETF) wrote: > That=E2=80=99s fine. It=E2=80=99s just my opinion. But as responsible AD = you can of course handle this as you like. Sure and thanks for that. The chairs did their analysis on the timeline and shared that with me. I think their analysis and justification is reasonable and I trust their judgement and don't want to micromanage the group as it's running just fine. Thanks, Kathleen > > Mirja > > >> Am 02.09.2016 um 18:36 schrieb Kathleen Moriarty : >> >> Hello, >> >> On Fri, Sep 2, 2016 at 9:54 AM, Mirja Kuehlewind (IETF) >> wrote: >>> Hi all, >>> >>> two comments: >>> >>>> Am 02.09.2016 um 15:41 schrieb Tero Kivinen : >>>> >>>> Also I would assume that during 2017 we most likely will get some new >>>> work items that will start working on, thus we will most likely want >>>> to do recharter by the end of 2017 anyways. >>> >>> If that=E2=80=99s the case I would recommend to remove the deadline fro= m the charter. Please note that if you end up without new work you can alwa= ys ask your AD to close the group (even without this deadline in the charte= r). >> >> I don't see why this is such an issue, including a deadline in the >> charter. It hasn't been a problem for the past 2.5 year (and for the >> AD for this group before). >> >> I'm fine with a deadline remaining in the charter. >> >>> >>>> And if there is nothing >>>> new to be done, and we have only 1-2 items left, we can continue >>>> working them without WG if needed. >>> >>> That=E2=80=99s usually not a good ideas. If you don=E2=80=99t have a wg= all docs need to be AD sponsored. If you have a wg you can just finish you= r doc, ask for reviews on the mailing, and run an WGLC to ensure there is e= nough review. You don=E2=80=99t have to have meetings or what ever. I don= =E2=80=99t see a reason to close a wg before the work is done (if there is = enough energy to finish the work). >> >> I can manage this with the WG. >> >> Thank you. >> >>> >>> Mirja >>> >> >> >> >> -- >> >> Best regards, >> Kathleen > --=20 Best regards, Kathleen From nobody Fri Sep 2 11:46:14 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EF31288B8 for ; Fri, 2 Sep 2016 11:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.59 X-Spam-Level: X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: DNS error: query timed out)" header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey6rz1b0fkwU for ; Fri, 2 Sep 2016 11:45:49 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E05126B6D for ; Fri, 2 Sep 2016 11:45:48 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id p41so71304179lfi.1 for ; Fri, 02 Sep 2016 11:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=9cnzlFliZoH7Q703KdhkOlKylP+/lB8WDz2OZBqfPUw=; b=SVsrWyiWf1SkmfNog/bDTtw5xNWz617G3VVbx0VgpIa0VaDUl6JBdl4lgtW1iGaucO 8+UTmbf+mCMW5u0d3P+LquEmgkV09DsJL55QnoR7HO4V+XXmTZL80DmTo4ZjXP2yi/ZG wPwOqoF63DNMnkqQzeR1e23rVeXqTRy3ORt+/36MtEAXbQ9FMM/U1fumrwwU8Y5E+aww T0zXGN8SXXLA0ojsyi1JL35qAkT1E6UXchku9IlRJNCE5SrWupxBG7mzldQATcM74ly/ jHxjmXVwr/FEDnkvEcwyYT0/RMWJ12GscrdGHSX9oRYhUpGa0ata/Fff2aqEko5c1JxM DlsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=9cnzlFliZoH7Q703KdhkOlKylP+/lB8WDz2OZBqfPUw=; b=bVcJ2Bd4WTe1z9dwpP5gWqapTrqbt1OV/YNFybZUGeEYyxlPRA3O7gF4KOPBPSgjNM j9pSX5RWmvX0seVtU5Gxk+EDWViBxNPfobheWcVd2AnX3vPI0Vu0vYtwxQL19x6BFbVV 2gVLjkmd5HhIQvQ09xZCbhRJfx5anlyZ61qLhRj61IWaqiSdS7JTF4Uwovi1fGq1GkaP HdDN5BmCLSxgudGfwzaTpzLXD2ti7oPol3l/y/MMFQCfQg7Lz/lfrGVegenGsmj/dprB LzG+6IMce26+PeV+n+7oxOSrB7bheUZ5ecb/2DC+WfCepKlqXfHFnjivq+dQPey6F6Xm 9rlQ== X-Gm-Message-State: AE9vXwOzvHBe+YfjsnY/KT2Gf3hyBT/xDYXH0IVM2GDCrrdg8czZNYOoKvN41cP5tHQr0A== X-Received: by 10.25.162.17 with SMTP id l17mr6349044lfe.125.1472841946804; Fri, 02 Sep 2016 11:45:46 -0700 (PDT) Received: from chichi (ppp83-237-163-119.pppoe.mtu-net.ru. [83.237.163.119]) by smtp.gmail.com with ESMTPSA id 89sm141535lfq.39.2016.09.02.11.45.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 02 Sep 2016 11:45:46 -0700 (PDT) Message-ID: <9CFB7B2AECC942E5A955BDE66B64E9DE@chichi> From: "Valery Smyslov" To: "Paul Wouters" , "Yaron Sheffer" References: <860ec25d-033d-b12d-541c-423caf3803d7@gmail.com> <16FF5F35-21F7-4789-84CF-5BB99645B13B@nohats.ca> <7e5bc7f3-9fe5-aa54-1d2f-be7da324250d@gmail.com> In-Reply-To: Date: Fri, 2 Sep 2016 21:45:40 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 18:46:13 -0000 > Hi Valery, > > Yes, these are lossy algorithms, but the TLS/HTTP attacks are all with > lossless algorithms. And as far as I know, they are applicable to any > situation where here is an attacker that can force traffic on the wire, > mixed with other, non-attacker controlled traffic. So IMO they are not > restricted to just HTTP. The attacks using compression known to me (e.g. CRIME) rely on the ability for an attacker to observe the difference in the length of messages (caused by applying compression) after each attempt. However, in case of ESP there are obstacles for doing that. First, ESP has a mandatory padding that is applied even in case of stream ciphers (in this case the packet is aligned to a 4 bytes boundary). This makes it more difficult for an attacker to catch a difference in lengthes. Then, ESP includes an optional TFC padding feature that makes the above attack infeasable, because each ESP packet will have either the same size or randomly adjusted size. And ESP compression could help applying TFC padding without consuming considerable anount of additional bandwidth. Regards, Valery. > Thanks, > Yaron From nobody Fri Sep 2 11:55:08 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0662512B00C; Fri, 2 Sep 2016 11:55:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147284250398.24754.10437452845713922604.idtracker@ietfa.amsl.com> Date: Fri, 02 Sep 2016 11:55:03 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] WG Review: IP Security Maintenance and Extensions (ipsecme) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 18:55:04 -0000 The IP Security Maintenance and Extensions (ipsecme) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2016-09-12. IP Security Maintenance and Extensions (ipsecme) ----------------------------------------------------------------------- Current status: Active WG Chairs: David Waltermire Tero Kivinen Assigned Area Director: Kathleen Moriarty Security Area Directors: Stephen Farrell Kathleen Moriarty Mailing list: Address: ipsec@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: https://mailarchive.ietf.org/arch/browse/ipsec/ Charter: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: IKEv2 contains the cookie mechanism to protect against denial of service attacks. However this mechanism cannot protect an IKE end-point (typically, a large gateway) from "distributed denial of service", a coordinated attack by a large number of "bots". The working group will analyze the problem and propose a solution, by offering best practices and potentially by extending the protocol. IKEv2 utilizes a number of cryptographic algorithms in order to provide security services. To support interoperability a number of mandatory-to-implement (MTI) algorithms are defined in RFC4307 for IKEv2 and in RFC7321 for ESP/AH. There is interest in updating the MTIs in RFC4307 and RFC7321 based on new algorithms, changes to the understood security strength of existing algorithms, and the degree of adoption of previously introduced algorithms. The group will revise RFC4307 and RFC7321 proposing updates to the MTI algorithms used by IKEv2 and IPsec to address these changes. There is interest in supporting Curve25519 and Curve448 for ephemeral key exchange and EdDSA for authentication in the IKEv2 protocol. The group will extend the IKEv2 protocol to support key agreement using these curves and their related functions. IKEv1 using shared secret authentication was partially resistant to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify IKEv2 to have similar quantum resistant properties than IKEv1 had. There have been middle boxes blocking IKE negotiation over UDP. To make IKE work in these environments, IKE and ESP packets need to be transmitted over TCP. Therefore the group will define a mechanism to use IKE and IPsec over TCP. The group will also provide guidance on how to detect when IKE cannot be negotiated over UDP, and TCP should be used as a fallback Split-DNS is a common configuration for VPN deployments, in which only one or a few private DNS domains are accessible and resolvable via the tunnel. Adding new configuration attributes to IKEv2 for configuring Split-DNS would allow more deployments to adopt IKEv2. This configuration should also allow verification of the domains using DNSSEC. Working group will specify needed configuration attributes for IKEv2. Currently, widely used counter mode based ciphers send both the ESP sequence number and IV in form of counter, as they are very commonly the same. There has been interest to work on a document that will compress the packet and derive IV from the sequence number instead of sending it in separate field. The working group will specify how this compression can be negotiated in the IKEv2, and specify how the encryption algorithm and ESP format is used in this case. This charter will expire in December 2017. If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Milestones: Mar 2016 - IETF Last Call on DDoS protection Mar 2016 - IETF Last Call on cryptographic algorithms for IKEv2 Mar 2016 - IETF Last Call on Curve25519 and Curve448 for IKEv2 From nobody Fri Sep 2 11:56:04 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54B712D54B for ; Fri, 2 Sep 2016 11:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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.548] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtVpA2tkE2AC for ; Fri, 2 Sep 2016 11:56:01 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C32012B015 for ; Fri, 2 Sep 2016 11:55:51 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sQpH92h7FzJtY; Fri, 2 Sep 2016 20:55:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1472842549; bh=of4s/CfN7G2262NRBaN5XjPsOIXIf4cOSeZPm9DleAM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=tGoCm+xhN3x5mb1B6toMWOz0O9c/6unKpU15VTtAj2tmP9mZU/d4IhNvcpVY3gwDz tMuvEx/uTyZeepAyHothZUndM2WlbaoY5TzSuv+biq6bMq2jUyZwDouqoHxysDa4sT v0tyxGHyqsWUt/ir9s8Y0h+HVBbuVgL/wmjvgj4A= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id n2xshlJowV7F; Fri, 2 Sep 2016 20:55:48 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 2 Sep 2016 20:55:48 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 74EE22ED948; Fri, 2 Sep 2016 14:55:47 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 74EE22ED948 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6F93E4163760; Fri, 2 Sep 2016 14:55:47 -0400 (EDT) Date: Fri, 2 Sep 2016 14:55:47 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: <9CFB7B2AECC942E5A955BDE66B64E9DE@chichi> Message-ID: References: <860ec25d-033d-b12d-541c-423caf3803d7@gmail.com> <16FF5F35-21F7-4789-84CF-5BB99645B13B@nohats.ca> <7e5bc7f3-9fe5-aa54-1d2f-be7da324250d@gmail.com> <9CFB7B2AECC942E5A955BDE66B64E9DE@chichi> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 18:56:03 -0000 On Fri, 2 Sep 2016, Valery Smyslov wrote: > And ESP compression could help applying TFC padding without consuming > considerable anount of additional bandwidth. You mean TFC pad to something that's not the MTU ? Not sure I see how compression + TFC makes smaller packets, unless your TFC padding is very small or zero, which presumably means the attaker can get it to become 0 for some cases? Paul From nobody Fri Sep 2 12:19:05 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E14712B00C for ; Fri, 2 Sep 2016 12:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MYKMXBDp9Vd for ; Fri, 2 Sep 2016 12:19:02 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4EC812B029 for ; Fri, 2 Sep 2016 12:19:01 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id b199so90576229lfe.0 for ; Fri, 02 Sep 2016 12:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=puzjk3twXJ8ZX45ys5400PSPokFG5tR5hNABRecJFBc=; b=EXsjAMtMn6NwWfEPbP0oEQz7pjgcutz6bD97w06LehISXW2qyaOSacbNFaUqoLng/4 pF4xSnCV9+YD1CGPB7T+xOgT8J8cLUQRQSNaUdUg/4Df2HOTo3QRus7mns1ulBmxfJXo HnfXYXylm+zVrv2Th32zYtMHL8qraFrnMD09bcR4Rm0Jmyf2+EUUdcfAh14gttgcCDNv jUF1uCuLBTBH5e3gdULBS9JWf/lTtfkmSnA+mmtx8HUT9w/ybLiuSOjg+qw4/5VEHX0W yEeURwExZnpehELQ8tBfM0ToUBAjyOR9Iwg3cikwcELPl0mIQlC/PzUp+aQA90wTZ+Rf F78g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=puzjk3twXJ8ZX45ys5400PSPokFG5tR5hNABRecJFBc=; b=GyGRh1b4UEE7AqV/shSx5JZems24xRhYiQcfOTstS0ZoVTcDDo6/NFg8rIOxDOb5g7 U8IaCoo6TfmxiLfi+cwJmevuEj3YN1zYDlqKGwDO19iHtWanbXbt30C6gWCOrTdn8XiT oqXFgn23orJrQVtwz6BN6bYdxtgRlQ1/PUTey13lAzL7tLrrxx1jUmfIvJBbPb5vzkSn /jD3OSWugmfFVoP6l4hFAnobLqXdC3NvhC8C5+CLZVzkPdbmcYWYo+3GnMGOvT8EOYlA 7yJHiSG+1w2YNe3bqFSmizOMtFtxidVE0ObqVHSHnhCvwZXyx3iZ6qrHV4ve3HU769i/ Y16A== X-Gm-Message-State: AE9vXwOMJxHNaPLK2fHhlLKx4VZkhojCFaApbK61fp+GSLDUaTsQLMp6k5ShqVpbMDiyxQ== X-Received: by 10.25.86.85 with SMTP id k82mr7653366lfb.65.1472843939715; Fri, 02 Sep 2016 12:18:59 -0700 (PDT) Received: from chichi (ppp83-237-163-119.pppoe.mtu-net.ru. [83.237.163.119]) by smtp.gmail.com with ESMTPSA id e185sm1501309lfb.24.2016.09.02.12.18.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 02 Sep 2016 12:18:58 -0700 (PDT) Message-ID: <98F4459E99FA4344AEF2F9B320EB3BA3@chichi> From: "Valery Smyslov" To: "Paul Wouters" References: <860ec25d-033d-b12d-541c-423caf3803d7@gmail.com> <16FF5F35-21F7-4789-84CF-5BB99645B13B@nohats.ca> <7e5bc7f3-9fe5-aa54-1d2f-be7da324250d@gmail.com> <9CFB7B2AECC942E5A955BDE66B64E9DE@chichi> In-Reply-To: Date: Fri, 2 Sep 2016 22:18:53 +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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 19:19:03 -0000 >> And ESP compression could help applying TFC padding without consuming >> considerable anount of additional bandwidth. > > You mean TFC pad to something that's not the MTU ? Probably, but not necessary. > Not sure I see how compression + TFC makes smaller packets, unless your > TFC padding is very small or zero, which presumably means the attaker > can get it to become 0 for some cases? It depends on the goal of TFC padding. To defend against CRIME-like attack it is enough to add some small (up to dozen or two) random number of bytes to each packet. Using compression helps not to earn (much) additional bandwidth in this case. Of course, if your goal is a full TFC, than you need to make each packet equal in size (and even better if you emit them at equal intervals). Valery. > Paul From nobody Fri Sep 2 19:33:32 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0537F12D5CC for ; Fri, 2 Sep 2016 19:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AuQJNkyAbMv for ; Fri, 2 Sep 2016 19:33:29 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0091.outbound.protection.outlook.com [23.103.201.91]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E9612D5C9 for ; Fri, 2 Sep 2016 19:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Qd/AYWzsUmDwcfjOzIZwc+2niv3buVfsbV+wthevX9M=; b=HwcX0wZUAurNpn+xo5hBQaw3bRf81nOjcZnL2oHIEw5Hr5EZYC9rcJ0YrdiaumDEYzZlHUX2TP9xQyHoE0FXuH4yBxvgD2nWWk+rhX40uaIpaNWpf8lrzIb6uMUAscjgaxpIP8MOSqbCKRJx4aiPurT/KzSKJEtH2r501leLEX4= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Sat, 3 Sep 2016 02:33:26 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0599.016; Sat, 3 Sep 2016 02:33:26 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: Call for adoption of draft-mglt-ipsecme-rfc7321bis as an IPSecME WG document Thread-Index: AdIFiu5YSsRPKyt0RkS9hutYx8w6eg== Date: Sat, 3 Sep 2016 02:33:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.220.18] x-ms-office365-filtering-correlation-id: ec5fd153-9c16-4936-87b5-08d3d3a2af4a x-microsoft-exchange-diagnostics: 1; MWHPR09MB1440; 6:g5FOvBNO4UVi//LwdTScRiH+s13c02s/payu8JqGBbJbsdx2zLcLaMVQkL+9OVg324tij7EMeauJMwBFVVLnaYEakm2nSWrcmTB/1ZJSZuNBu+iOpqu3DdaEXqbe/mefivP1M22YrTC0FnbETfuvl/N7J80HUqrNQJr/cNG+71DHO3C9BcBuMUDdAyiLM0S9gQ79v3fNSdc5yEeeCBP58YoGrix2mWqlk7KZ2r3UbOt2rwbus6y7NRq7osOT3Lk6t4U6TTk6TQ0bb0bpBN32zhLgzSdkpyQp0LeZhITJjKAnMQX7rL7yVXSYkOUlUImZGv0Q+E4SY1wrnuvNZp1W4A==; 5:iWuE9FgnF2d/mXm/6U9JfkgCId7JNcBq7iN8ve4+f8jeXxv7ZuOMLusXnrbHCAsjd0DfPA4OP6KM0bnBY83A9glqbwK5luHhVr8LvSxYB3UtvAbwG3pomdKkeHXsSSI8WPP8Wc/85p9g37xCbaiabw==; 24:uUrh9pSz6aY5Mx4La1oblDdAUgTDd1u11YEFrmHvIzXcF4LfOgE+gbEy9owpVygApReyzrjEKdaPCAeI0mCgq578vF6SccsyE8CQ+hDlQ9A=; 7:mLa+HM1cc0rgyH0HRvKNl77cQdwsB9Zr2CXgDrjHXMpOf8fgetiSyVCoOh9uvDF6DvwCXNuK3yqVxb2AHMdgyPEtk6UtTTCTfYBar8Is34ZYfU+faerwhIVAkJw4vJY33c6OCYD/XWyYnL0dtj+GVCQZZSDcUDBpVS2++E30+8bveTg/JOH5IK/TfZWzZBYhNyZbRBLePD05nnDVJqm8hlACccHkyTLMWjbYYJT8W1Ph77raLUTpRje4Qvptuvgd x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR09MB1440; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:MWHPR09MB1440; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1440; x-forefront-prvs: 00540983E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(68736007)(8676002)(10400500002)(122556002)(74316002)(5660300001)(33656002)(229853001)(97736004)(101416001)(86362001)(54356999)(50986999)(81166006)(81156014)(8936002)(92566002)(19580395003)(11100500001)(5002640100001)(3280700002)(586003)(450100001)(189998001)(6116002)(3846002)(102836003)(15975445007)(305945005)(99286002)(9686002)(2906002)(7696003)(106356001)(7736002)(7846002)(76576001)(2900100001)(230783001)(87936001)(105586002)(3660700001)(66066001)(110136002)(77096005)(107886002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1440; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2016 02:33:26.5269 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1440 Archived-At: Subject: [IPsec] Call for adoption of draft-mglt-ipsecme-rfc7321bis as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 02:33:31 -0000 This is the call for adoption of https://datatracker.ietf.org/doc/draft-mgl= t-ipsecme-rfc7321bis/ as an IPSecME working group (WG) document.=20 By adopting this draft, the WG is agreeing to take this on as an official W= G item to continue work on the draft. Please reply to this message with any= comments supporting or concerns against adopting this draft. This call wil= l run until Wednesday, September 14th, 2016 UTC 23:59. Thanks, Dave and Tero From nobody Fri Sep 2 19:35:32 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F10D12B016; Fri, 2 Sep 2016 19:35:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147287013127.24853.5185750485415914578.idtracker@ietfa.amsl.com> Date: Fri, 02 Sep 2016 19:35:31 -0700 Archived-At: Subject: [IPsec] The IPSECME WG has placed draft-mglt-ipsecme-rfc7321bis in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 02:35:31 -0000 The IPSECME WG has placed draft-mglt-ipsecme-rfc7321bis in state Call For Adoption By WG Issued (entered by David Waltermire) The document is available at https://datatracker.ietf.org/doc/draft-mglt-ipsecme-rfc7321bis/ From nobody Fri Sep 2 19:41:23 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4570012D5CC for ; Fri, 2 Sep 2016 19:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSG6hDQKG0e4 for ; Fri, 2 Sep 2016 19:41:19 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0134.outbound.protection.outlook.com [23.103.200.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829C912B016 for ; Fri, 2 Sep 2016 19:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Od7LPX/FFaPzfrdBNFtfTvRh7zPtlHvGaGiie5ZNniI=; b=IDfZqWGif/85DIeaHlen0uSIgt3HNWhSH6y/PWe7GaxtG6wMKlbR1S96QmcWh3J7FzMMmO3mtHhxUVeU/3ayZfXfJWel947kmSP5N1tKsIAybFZUZfY8LBV953yoC29TTYN5Qe/g3y5vi3ION1XL5zZsHktf5g4RyAcXGIM5/Ec= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1438.namprd09.prod.outlook.com (10.173.50.12) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Sat, 3 Sep 2016 02:41:18 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0599.016; Sat, 3 Sep 2016 02:41:17 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: WGLC on draft-ietf-ipsecme-rfc4307bis-11 Thread-Index: AdIFjEsiiAZg58SjSQuP1+89T+2nUg== Date: Sat, 3 Sep 2016 02:41:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.220.18] x-ms-office365-filtering-correlation-id: 1d76aa15-9840-478c-e873-08d3d3a3c819 x-microsoft-exchange-diagnostics: 1; MWHPR09MB1438; 6:8gCpqZae+LxADHcNi6s3GGxpxsEMVLcRhJi71Yu3StChVa14PUjzzerOPz9qbaAwc8S54ivIYeZjjjsqyFzNOzyZ+mP5t/Fv1D7tTlTOyLPIvXMDqsrLOPb8/RMSYdA+AYjReGy3ipeFnDX7haPXW0kle4hDYAJoc63AN/RuIOLN/5DUHcO7Rm+fR/TUfiHtXEqLF6ut7NDv2HQlKjQTAY/rkKJUpmtjr07fSLeuJjRXPjYEZPneveNWyqMnqW3u6Esuov5gwvjkex62DL5b4Y6yBUna+ikXOEsi/Xx8UdhDedK47c8xGb2hX4qxG1UjOHc7lAepxMFLo7A9+PYHMg==; 5:ZOzGnlYWS7SzDcR7GJyUCbkwa3iitmLnPvYyQUrgiMIqThj9z9b9YCKZUnIWLzwn7/XslYvBVE6WE0wueVQP8MIG5STluV167epkFMG303WEuSh9JczkSkhNBnF2pbeKnhY/vBGisVRcqglNkDc2Pg==; 24:PuJlmGVDZKUXmQ5c4uF1Ki2aR1Ht6yDb7Z46w6YploPpAZcEelUSccxU8BmkDWC2AFgClO8aJQ4ZjPWb7iFog3pMfC0XRRZ9ysORqSy8PfU=; 7:8mOKjMhKzWzcO/NwqzlEGf9svSAn4oiuKZIQ8AmYvCTXAaLlcGGsgl7l8jiq/XC4YFN/4ynz3yc50TghQpHukHOMKeWJW5aBey6wY1MizLu21suhFFtkanaR779aVHdDVQBlYuM5cDwXXibB/NDomrW30k4EKHbQzjJIQf6kuD/j6WQ2MD++FAq3seXpV+IcWKa58lC7BAgbGN7EZ4VjgSAgabV9UnQXatMUu31tzOF605/AVTz6OgDFZXcL6UGN x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR09MB1438; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:MWHPR09MB1438; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1438; x-forefront-prvs: 00540983E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(6116002)(3280700002)(8676002)(68736007)(586003)(74316002)(81166006)(81156014)(106356001)(189998001)(97736004)(7846002)(3660700001)(2900100001)(230783001)(15975445007)(7736002)(92566002)(7696003)(305945005)(86362001)(2906002)(122556002)(87936001)(107886002)(102836003)(3846002)(110136002)(8936002)(77096005)(5660300001)(9686002)(101416001)(10400500002)(105586002)(19580395003)(50986999)(76576001)(99286002)(5002640100001)(33656002)(229853001)(66066001)(450100001)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1438; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2016 02:41:17.4929 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1438 Archived-At: Subject: [IPsec] WGLC on draft-ietf-ipsecme-rfc4307bis-11 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 02:41:21 -0000 All, This message starts a Working Group Last Call (WGLC) for draft-ietf-ipsecme= -rfc4307bis-11. The version to be reviewed is https://www.ietf.org/id/draft-ietf-ipsecme-rf= c4307bis-11.txt. Please send your comments, questions, and edit proposals to the WG mail lis= t until September 19th, 2016. If you believe that the document is ready to= be submitted to the IESG for consideration as a Standards Track RFC please= send a short message stating this. Best Regards, Dave and Tero From nobody Fri Sep 2 20:00:38 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471AE12D53B for ; Fri, 2 Sep 2016 20:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vubVNJr4JPR4 for ; Fri, 2 Sep 2016 20:00:35 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0115.outbound.protection.outlook.com [23.103.201.115]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB7812D08C for ; Fri, 2 Sep 2016 20:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+fw5YtL/VkYUdvtxpeB6v58EVTZUMcLWw+t0b92zeyU=; b=vcukA6A+9EbAZZCSgVV7hXRxlLjY+1sVni4hp9QHfLqh4oooCnWGQ+CpLAwfRTSuPDgG48e5CXMA1DYFRb+GTjEXRW+0tUY9slFTVILfFMJlEFPKOX0grSVoWu8EqCe5ZBt3WPh8Ai1STJC+YvxkkDdV+vVTJxJGHzyLSKyUBVo= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1438.namprd09.prod.outlook.com (10.173.50.12) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Sat, 3 Sep 2016 03:00:33 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0599.016; Sat, 3 Sep 2016 03:00:33 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: IPsecME Status update 2016-09-02 Thread-Index: AdIFjuookDNTh1lJR/2jkcJqYMoIgw== Date: Sat, 3 Sep 2016 03:00:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.220.18] x-ms-office365-filtering-correlation-id: a2fe574f-e9b4-4bdc-8316-08d3d3a678ec x-microsoft-exchange-diagnostics: 1; MWHPR09MB1438; 6:y9fIfzP8Osl8c0iMiguQMJmNCct1HltSfhRGgxvJy+cJkQapPcGReEywZlHOaHAAEvZluR+SvGwKsjHFvgYGTKfV21lBcJC5h1d/tpYUpJ1jS7pslas/2VkLKabOTpWG6mJupU74fZpI/3FHr8Wr3wDiwJizW0Ofu9VH/wIzsU00mgVhibWY7lzUuow0PGdeWYHi1ZAzrkKcx1OO0N/yt1L6EWrDTL3rzREsASoba6ge7eyclJFefuhbBJme5Ffo41Lex2PPrKDyVIOnLChXqjqvL5VTSERDJ54qJX7GTErTM9LzdqVtSIZ4an+bWL9uTnlk2FaWa1CFqA/coy0N2A==; 5:rquFUG00mLIM60CYi6aqloDH+/9YFFyOjr6qqQ+ctSW5Mji5Bvv344XXtHceJihLIbuCyT8L/iyc7l276Ww4m4JJH+Nctvyy++sEAU+iLW+zxoKDOYajmZ2o+v1ZVfB0zjEjsjffzI58pOns86AOUA==; 24:jyF46G9adx4xabyKrhWONO8HnUBZWvwkycu+vQdbkDUjX1kr3hggJa9NDZgnmY/VLahSeDp2FeWPArXLC5djoJ9Ub+TrorJNXFSxzCTAQ+A=; 7:nrOYFWAw4FdmfiWCmVHLhEiO5MFJjezPD5myaRgzs51iKQQKNpc17Kop3oI05GEnbqJMvaDKrwtqvIb1+b55c2+wmoAWg1/QD1Egl/kPVzxDt27pGOxugypVUsMRrRmuwSde5wHEh5l3QGTDr0K2zZ0K27tbYlCn+Hr/KzJmX5LN1/p62Q2FQz4dbocf1MRpbz6kt1k6BVWi66K3C5C4Fk85KNgAUiaOBHBYqmHYKK3+9qP9bI15OEbTKW+FE/7T x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR09MB1438; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:MWHPR09MB1438; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1438; x-forefront-prvs: 00540983E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(5423002)(377424004)(199003)(101416001)(9686002)(5660300001)(50986999)(19580395003)(10400500002)(105586002)(8936002)(77096005)(229853001)(54356999)(66066001)(11100500001)(99286002)(76576001)(15650500001)(33656002)(5002640100001)(106356001)(189998001)(7846002)(97736004)(3280700002)(68736007)(74316002)(8676002)(586003)(6116002)(110136002)(81166006)(81156014)(86362001)(2906002)(305945005)(7736002)(7696003)(92566002)(102836003)(4326007)(87936001)(122556002)(3846002)(2900100001)(230783001)(3660700001)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1438; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2016 03:00:33.3077 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1438 Archived-At: Cc: "Kathleen.Moriarty.ietf@gmail.com" Subject: [IPsec] IPsecME Status update 2016-09-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 03:00:37 -0000 Charter update The charter is currently under review by the IESG. A new version was posted to address some of the IESG feedback on 2016-09-02. Thanks to Kathleen for her help with the edits. No objection on the list. Should go forward, on the 2016-09-15 IESG telechat. https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ Document Status: - draft-ietf-ipsecme-ddos-protection (David) Submitted to the IESG on 2016-08-18. Requested for publication as a Proposed Standard. - draft-ietf-ipsecme-rfc4307bis (David) WGLC issued for -11 on 2016-09-02. The call will close on September 19th, 2016. - draft-mglt-ipsecme-rfc7321bis (David) Call for adoption was issued on 2016-09-02. The call will close on September 14th, 2016 UTC 23:59. - draft-ietf-ipsecme-safecurves (Tero) Submitted to the IESG on 2016-08-30. Requested for publication as a Proposed Standard. - draft-nir-ipsecme-eddsa (Tero) I think this is still waiting for the curdle to decide for OID, but we could start WG adaptation call, as this is now in our charter, and this is good starting point. - draft-ietf-ipsecme-tcp-encaps (Tero) This should also be ready for WGLC.=20 New work: - Quantum Resistance (David) Discussion has started on the mailing list about the requirements and when we have those decided on the list, we should start working on document. - draft-pauly-ipsecme-split-dns (David) This was accepted as charter item, but need few more reviews before taking it as WG draft.=20 - draft-mglt-ipsecme-implicit-iv (Tero) This was also accepted as charter item, but would like to see few more reviews before taking it as WG draft. From nobody Mon Sep 5 07:39:34 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3B112B21C for ; Mon, 5 Sep 2016 07:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKEnPOJQiBtp for ; Mon, 5 Sep 2016 07:39:32 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A2E112B22B for ; Mon, 5 Sep 2016 07:39:31 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u85EdHRI018731 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 Sep 2016 17:39:17 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u85EdCqM017686; Mon, 5 Sep 2016 17:39:12 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22477.33680.692346.114261@fireball.acr.fi> Date: Mon, 5 Sep 2016 17:39:12 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: References: <860ec25d-033d-b12d-541c-423caf3803d7@gmail.com> <16FF5F35-21F7-4789-84CF-5BB99645B13B@nohats.ca> <7e5bc7f3-9fe5-aa54-1d2f-be7da324250d@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 12 min X-Total-Time: 11 min Archived-At: Cc: ipsec@ietf.org, Valery Smyslov , Paul Wouters Subject: Re: [IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 14:39:33 -0000 Yaron Sheffer writes: > Yes, these are lossy algorithms, but the TLS/HTTP attacks are all with > lossless algorithms. And as far as I know, they are applicable to any > situation where here is an attacker that can force traffic on the wire, > mixed with other, non-attacker controlled traffic. So IMO they are not > restricted to just HTTP. There is big difference in the TLS and ESP that in the TLS the compression is statefull, so if I send text "foobarzappa" earlier, and then later in the session send the same string, that string will get compressed. In the ESP this will only happen if you send it inside the same packet. I.e., i.e., you can use the compression to check the lengths if you can make one end to send packet where parts of the packet comes from the attacker, and parts of it comes from somewhere else, and attacker wants to verify whether his guess on the text on the other parts are correct. There are ways to use those attacks also against ESP, but I think they are harder than against TLS, and also the main reason they worked for the TLS, was because TLS allowed attackers to run code on the target machine (javascript), which was then used to send trial stuff over the same compressed link. Anyways, I do not think compression is that widely used, and having it as MAY is fine. We could add some note warning about the risks of using compression. I.e., using compression, might leak out information about the data transmitted over the ESP, and it might be good idea not to enable compression if full confidentiality is required. On the other hand on some IoT or similar environments, where every byte counts, it might be useful to have compression. Also in some of those environments authentication and authorization is much more important than confidentiality. -- kivinen@iki.fi From nobody Mon Sep 5 10:50:31 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BEF12B423 for ; Mon, 5 Sep 2016 10:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 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=-1.508] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS6FMsADeEwV for ; Mon, 5 Sep 2016 10:50:28 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25A4012B27B for ; Mon, 5 Sep 2016 10:50:28 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sSchK39Yrz3lY for ; Mon, 5 Sep 2016 19:50:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1473097825; bh=rI9gwIfwSKmRj76dUFYl6WTISlj0DJlG+FkyO7FqIzQ=; h=Date:From:To:Subject:In-Reply-To:References; b=IX7LxbBICOUjx81FFQwiftPVOGDv02Hh+YeYz288RABQWOS/4i6EpwS5GtVEiLLSm pfOTD11G1OCK84TVBh+d9E21z3ZySTMXy4AWr8REpFkOySSg1UoUhiLN3l/+Y/qAo3 +fas6Bwqvi4LwGQ7fs/TuGK38maIgHXhjR7OwSN4= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 18WuV2tYw2wL for ; Mon, 5 Sep 2016 19:50:24 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Mon, 5 Sep 2016 19:50:24 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B147C19C32B; Mon, 5 Sep 2016 13:50:21 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca B147C19C32B Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8E39540D729F for ; Mon, 5 Sep 2016 13:50:21 -0400 (EDT) Date: Mon, 5 Sep 2016 13:50:21 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-rfc4307bis-11 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 17:50:29 -0000 On Sat, 3 Sep 2016, Waltermire, David A. (Fed) wrote: > This message starts a Working Group Last Call (WGLC) for draft-ietf-ipsecme-rfc4307bis-11. > > The version to be reviewed is https://www.ietf.org/id/draft-ietf-ipsecme-rfc4307bis-11.txt. > > Please send your comments, questions, and edit proposals to the WG mail list until September 19th, 2016. If you believe that the document is ready to be submitted to the IESG for consideration as a Standards Track RFC please send a short message stating this. And since a lot of the regular active people on this list are co-authors, it is extra important to hear from others! Paul From nobody Tue Sep 6 14:09:57 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DC812B0DD for ; Tue, 6 Sep 2016 14:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.028 X-Spam-Level: X-Spam-Status: No, score=-16.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiO-WDh9niho for ; Tue, 6 Sep 2016 14:09:54 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D908C12B0B5 for ; Tue, 6 Sep 2016 14:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17905; q=dns/txt; s=iport; t=1473196193; x=1474405793; h=from:to:subject:date:message-id:mime-version; bh=T6a2/eFIAzzPMfm6sPjohVWbCDLyyl8YqW9/YlY/mec=; b=Qm2/rw1nBY2CeT8AekfaL4JCOjkkt2GLLccfO5x5urHqWPZK2MmqWJTC bf9ygh8zcjpNSeeBwfRjxlxH7h0Sx8s3wtQNn1c7UzUoMPZOVK9LZYbjQ ZNeXVEsrQBLixpG3tgciazaUmZ9sjRmsHXFZInSR/G0FXeoAiuyQngkeh o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAQA4MM9X/5NdJa1UCRoBAQEBAgEBA?= =?us-ascii?q?QGCejMBAQEBAR5XfAeNJ6sIggKHfzgUAQIBAQEBAQEBXieEYQEBBS1eAQgQAQQ?= =?us-ascii?q?BAWEdCQEEEwgTiC+gEZwJAQEBAQEBBAEBAQEBAQEghi+EToQZhgMFiRCQQwGPL?= =?us-ascii?q?o9gjEyDeQEeNoRHcIU+fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,293,1470700800"; d="scan'208,217";a="318383548" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Sep 2016 21:09:52 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u86L9p6R010502 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 6 Sep 2016 21:09:51 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Sep 2016 17:09:50 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Tue, 6 Sep 2016 17:09:50 -0400 From: "Scott Fluhrer (sfluhrer)" To: "IPsecme WG (ipsec@ietf.org)" Thread-Topic: Quantum Resistance Requirements Thread-Index: AdH0G8ijQKeg6MaXRiG9vXmtSf0/rwUZFu7A Date: Tue, 6 Sep 2016 21:09:50 +0000 Message-ID: <29427d45853b4e01b6e38674f8570721@XCH-RTP-006.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.60] Content-Type: multipart/alternative; boundary="_000_29427d45853b4e01b6e38674f8570721XCHRTP006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 21:09:56 -0000 --_000_29427d45853b4e01b6e38674f8570721XCHRTP006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Last month, I listed a series of potential requirements for a shortterm Qua= ntum Resistance solution; several people have commented on these requiremen= ts, and here are the votes so far (omitting the "no opinion" votes); I've l= isted the voters chiefly so that if I mischaracterized their votes, they ca= n correct me: From: Scott Fluhrer (sfluhrer) Sent: Thursday, August 11, 2016 6:01 PM To: IPsecme WG (ipsec@ietf.org) Subject: Quantum Resistance Requirements - Simplicity; how large of a change to IKE (and IKE implementation= s) are we willing to contemplate? Scott Fluhrer: very important Michael Richardson: very important Tommy Pauly: very important Valery Smyslov: not as important as other issues o My opinion: minimizing changes to IKE should be given high priority, bo= th because "complexity is the enemy of security" and this is a short term s= olution; if we have a solution that we can't implement in a few years, well= , we might as well wait for the crypto people to give us the long term one. - Preserving existing IKE security properties? Scott Fluhrer: very important Michael Richardson: very important Tommy Pauly: very important Valery Smyslov: important - What do we feel needs to protected from someone with a Quantum C= omputer? Do we feel the need to protect only the IPsec traffic, or do we = need to protect the IKE traffic as well. Tommy Pauly: not clear if IKE traffic needs to be protected. Valery Smylsov: important - What level of identity protection do we need to provide? If two= different IKE negotiations use the same shared secret, do we mind if someo= ne can deduce that? Scott Fluhrer: not important Michael Richardson: very important Tommy Pauly: not important Valery Smylsov: this is a nice to have, but not critical - PPK management; how much support do we provide for automaticall= y managing the secrets? Scott Fluhrer: not important Tommy Pauly: not important - How much support do we provide for nonstatic secrets, for exampl= e, by QKD, or via something like HIMMO (a key distribution mechanism that a= ppears to be post quantum)? Scott Fluhrer: not important Michael Richardson: not important Tommy Pauly: not important - Authentication; if someone with a Quantum Computer can break the= DH in real time, do we care if he can act as a man-in-the-middle? Scott Fluhrer: not important Michael Richardson: important, provided that we don't run into the same iss= ues that IKEv1 PSKs ran into Tommy Pauly: not important Valery Smylsov: this would be nice to have - Algorithm agility; how important is it that we negotiate any cry= ptoprimitives involved? Scott Fluhrer: not important Tommy Pauly: not important Valery Smylsov: important --_000_29427d45853b4e01b6e38674f8570721XCHRTP006ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Last month, I listed a series of potential requirements for a shortte= rm Quantum Resistance solution; several people have commented on these requ= irements, and here are the votes so far (omitting the “no opinion” votes); I’ve listed the voter= s chiefly so that if I mischaracterized their votes, they can correct me:

 

From: Scott Fl= uhrer (sfluhrer)
Sent: Thursday, August 11, 2016 6:01 PM
To: IPsecme WG (ipsec@ietf.org)
Subject: Quantum Resistance Requirements

 

 

-     &= nbsp;    Simplicity; how large of a change to IKE (and IKE i= mplementations) are we willing to contemplate?

Scott Fluhrer: very im= portant

Michael Richardson: ve= ry important

Tommy Pauly: very impo= rtant

Valery Smyslov: not as= important as other issues

 

o   My opinion: minimizing changes to IKE should= be given high priority, both because “complexity is the enemy of sec= urity” and this is a short term solution; if we have a solution that = we can’t implement in a few years, well, we might as well wait for the crypto people to give us the long term one.

 

-   &= nbsp;      Preserving existing IKE security proper= ties?

Scott Fluhrer: very im= portant

Michael Richardson: ve= ry important

Tommy Pauly: very impo= rtant

Valery Smyslov: import= ant

 

 

 

-     &= nbsp;    What do we feel needs to protected from someone wit= h a Quantum Computer?  Do we feel  the need to protect only the I= Psec traffic, or do we need to protect the IKE traffic as well.<= /p>

Tommy Pauly: not clear= if IKE traffic needs to be protected.

Valery Smylsov: import= ant

 

 

-     &= nbsp;    What level of identity protection do we need to pro= vide?  If two different IKE negotiations use the same shared secret, d= o we mind if someone can deduce that?

Scott Fluhrer: not imp= ortant

Michael Richardson: ve= ry important

Tommy Pauly: not impor= tant

Valery Smylsov: this i= s a nice to have, but not critical

 

 

-     &= nbsp;     PPK management; how much support do we provid= e for automatically managing the secrets?

Scott Fluhrer: not imp= ortant

Tommy Pauly: not impor= tant   

 

 

-     &= nbsp;    How much support do we provide for nonstatic secret= s, for example, by QKD, or via something like HIMMO (a key distribution mec= hanism that appears to be post quantum)?

Scott Fluhrer: not imp= ortant

Michael Richardson: no= t important

Tommy Pauly: not impor= tant

 

 

-     &= nbsp;    Authentication; if someone with a Quantum Computer = can break the DH in real time, do we care if he can act as a man-in-the-mid= dle?

Scott Fluhrer: not imp= ortant

Michael Richardson: im= portant, provided that we don’t run into the same issues that IKEv1 P= SKs ran into

Tommy Pauly: not impor= tant

Valery Smylsov: this w= ould be nice to have

 

 

-     &= nbsp;    Algorithm agility; how important is it that we nego= tiate any cryptoprimitives involved?

Scott Fluhrer: not imp= ortant

Tommy Pauly: not impor= tant

Valery Smylsov: import= ant

 

 

 

--_000_29427d45853b4e01b6e38674f8570721XCHRTP006ciscocom_-- From nobody Fri Sep 9 04:44:55 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6241A12B340 for ; Fri, 9 Sep 2016 04:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsE9t4YoQ9NE for ; Fri, 9 Sep 2016 04:44:52 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA4712B33E for ; Fri, 9 Sep 2016 04:44:52 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u89Bim5s008252 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 9 Sep 2016 14:44:48 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u89BimEA010422; Fri, 9 Sep 2016 14:44:48 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22482.41136.225817.613137@fireball.acr.fi> Date: Fri, 9 Sep 2016 14:44:48 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 26 min X-Total-Time: 43 min Archived-At: Subject: [IPsec] RFC4307bis and RFC7321bis: summary of changes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 11:44:54 -0000 Both of them still miss the summary of changes since 4307 and and 7321 sections. Now when we hopefully have agreed on what changes are going to make, so we might want to add summaries: ---------------------------------------------------------------------- Algorithms mentioned in the RFC4307 were changed as follows: Algorithm In RFC4307 Now --------- ---------- --- ENCR_3DES MUST- MAY ENCR_NULL MUST NOT[errata] - ENCR_AES_CBC SHOULD+ MUST ENCR_AES_CTR SHOULD - PRF_HMAC_MD5 MAY MUST NOT PRF_HMAC_SHA1 MUST MUST- PRF_AES128_XCBC SHOULD+ SHOULD AUTH_HMAC_MD5_96 MAY MUST NOT AUTH_HMAC_SHA1_96 MUST MUST- AUTH_AES_XCBC_96 SHOULD+ SHOULD Group 2 (1024-bit) MUST- SHOULD NOT Group 14 (2048-bit) SHOULD+ MUST ---------------------------------------------------------------------- Algorithms mentioned in the RFC7321 and which were changed, were changed as follows: Algorithm In RFC7321 Now --------- ---------- --- ENCR_AES_GCM_16 SHOULD+ MUST ENCR_AES_CCM_8 MAY SHOULD ENCR_AES_CTR MAY - ENCR_3DES MAY SHOULD NOT AUTH_HMAC_SHA1_96 MUST MUST- AUTH_AES_128_GMAC SHOULD+ MAY AUTH_NONE MAY MUST / MUST NOT ---------------------------------------------------------------------- I think we should add those sections before we go to the IETF LC. Those sections will make it easier for others to see what we did also. Btw, we did change every single requirement from RFC4307... for RFC7321 we did leave some of the requirements intact... -- kivinen@iki.fi From nobody Fri Sep 9 10:07:24 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2349C12B0D0; Fri, 9 Sep 2016 10:07:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.32.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147344084413.30945.9348192438270139200.idtracker@ietfa.amsl.com> Date: Fri, 09 Sep 2016 10:07:24 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-12.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 17:07:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Algorithm Implementation Requirements and Usage Guidance for IKEv2 Authors : Yoav Nir Tero Kivinen Paul Wouters Daniel Migault Filename : draft-ietf-ipsecme-rfc4307bis-12.txt Pages : 18 Date : 2016-09-09 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for IKEv2 and does minor cleaning up of IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 9 11:31:46 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D1012B1E2 for ; Fri, 9 Sep 2016 11:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZNEgEUYcPKE for ; Fri, 9 Sep 2016 11:31:43 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E752912B1E1 for ; Fri, 9 Sep 2016 11:31:42 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id 95so50802436uaz.2 for ; Fri, 09 Sep 2016 11:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=o/4wiZSPHtGzDHY2lsdD7Vu7AD/I39Vk8wGyrJ94N2E=; b=JJ7HSg5YgugD3/ISt9+R9aaWjcKpCCOKlCEK+5d7ZOcq86yOh73OCkmA5ucFXix+vi LRhX/hZ47s3XhP8Pg0HuMehcqA47sSDU1g7QGo5VOXMT1lt50s72YaS8lQYSx2lT3B5f B/GuG2CMd8GfT1OeJ4bg8jF5VUJnJ97I06nBxqZzSfqZUsVMN8zUH98GQjvIheoz2HVQ lACNOly3HlkMVSkDzRj6GCVbmiySQr1KTDKmuhlWiEG6ZxQNNf6DLVQCymg+d2C7I1gK SPB8voizc3OIT6xZbqqTH83djA+O7mU+lr+shxYnNoaYnHPo2ebyQAJh3CBmqd0GaM9Z TkLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=o/4wiZSPHtGzDHY2lsdD7Vu7AD/I39Vk8wGyrJ94N2E=; b=QT712hEifARAiL9KtPTHx6g2MVsgY/1PZSMQlOI9FC50847cbqnrJ87NoNXN8M4t6k sVUgxYEEgBwq53jynHMkqMQBg2c6dC3rOiPk2cqpkxHVNruoBt5SMGswK2bO9i+3HJdX SrI6jMxofvHr7pNI13E6AMQjmor2I3sQeFZwO8rvSjU7G1jXLF+MdOGsO6WoqvladOhV nzkEc2BdEudvmA0jJinq3p/Q/+Nu/ia0GojTLYq5IKcckIJQj+o3gliMyyxEPwWB1+OG b0uu8v/OfffDzd/yvgzEwT0h6UGJNC7TDNy45qqUuEfhwV35s+e6CoO6l5AsqAMcZo49 AHmw== X-Gm-Message-State: AE9vXwPDK1Y3pGOOZCaCXLGtVVRMCz3nqcutqqvAN7Y4sW27VykCTWh2LI67Qk7AiHaSlgW1LndJXutaEHGLzA== X-Received: by 10.176.1.3 with SMTP id 3mr3561506uak.88.1473445901985; Fri, 09 Sep 2016 11:31:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.8 with HTTP; Fri, 9 Sep 2016 11:31:41 -0700 (PDT) From: Kathleen Moriarty Date: Fri, 9 Sep 2016 14:31:41 -0400 Message-ID: To: "ipsec@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [IPsec] AD review of draft-ietf-ipsecme-ddos-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 18:31:45 -0000 Hello, Thank you for you work on draft-ietf-ipsecme-ddos-protection. This is a good read that lays out the problem well and describes the solution well. Thanks for that! I have some nits and questions before we put this into IETF last call. Section 4.2 - This level of detail is great. Hopefully developers make sure logs and other ways to help with troubleshooting to determine the number of half open SA and failed IKE-Auth exchanges. Are these maintained with counters (SNMP/YANG) or log entries or some other way? Does this matter and does it need to be indicated here for developers so implementors have the tools needed to determine next steps? Section 4.6: Suggest using some descriptive language instead of saying 'garbage' in the following sentence for non-native English speakers: The attacker can just send garbage in the IKE_AUTH message forcing the Responder to perform costly CPU operations to compute SK_* keys. Same in section 4.7, maybe "meaningless bits" or something along those lines? Malicious initiators can use this feature to mount a DoS attack on the responder by providing an URL pointing to a large file possibly containing garbage. Section 7.1.1.2: The following sentence could be cleaned up a bit (last paragraph): The initial request message sent by the Initiator contains an SA payload with the list of transforms the Initiator supports and is willing to use in the IKE SA being established. Section 7.2.1.1 The first sentence of course fits in this section, but has already been said in the draft. This whole section seems repetitious. There are a few places where text is repeated, is it possible to reduce repetition? It might not be for clarity as the sections vary, but an effort to reduce it might make the latter part of the draft as easy to read as the start. Section 7.2.4: 4th paragraph, 1st sentence doesn't read well. Can you break it up and phase the "non-first" differently? I don't think that is a term of art, is it? If the Initiator uses IKE Fragmentation, then it is possible, that due to packet loss and/or reordering the Responder could receive non- first IKE Fragment messages before receiving the first one containing the PS payload. Thank you! -- Best regards, Kathleen From nobody Fri Sep 9 12:03:15 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B241A12B2E7 for ; Fri, 9 Sep 2016 12:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCB9WvVjAJ9T for ; Fri, 9 Sep 2016 12:03:12 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28AE128874 for ; Fri, 9 Sep 2016 12:03:12 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id u68so76010060uau.1 for ; Fri, 09 Sep 2016 12:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=AsTxlqXGRegH6QyL7WUT3EH+/Z26T4M90U0S2g3steo=; b=kBjJLvdJVLTOigd0Wa8MWOJiB8BnA2i4M5fJ1/2hyq2QLCkdEiFGJAtnq4F2U+kKYH XSq1ype3Grh2wcqjcWeO2NYjsKOFBbtn2L7YSDwKskFwvj/djAC6jRm7ayf5rYVLaEfI OoGwOhcn7xlMUuNWea7UQCMXfyciak3F5qurJqBIdmrywBXl4I4N0hPQG0hpKk+QADkQ zTPiblJ9JHGnZIaDDRP70E1MEBHO6omli/shxsZAY2PwLMMIAECG+Q6nZz6pNgJtYJsw NDElvqDYrR3+gqY3Q1SGBeDDktHYtc9cdDDgnwrJBYDjRDVtyeoOXj1GbM1hUyR9j6wz oTDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AsTxlqXGRegH6QyL7WUT3EH+/Z26T4M90U0S2g3steo=; b=mqqSHtZK1ttD+IfjF61INYbwDbVZf2u112xVshHIng4LivASQOR7cMoCY61HP1iVGu +fO6Uc/3vqruDOqnVDpa9xaZwoom9fPN9YDHZLP4S/oFtuw2d466D9+8K6USWhvJyLGg N2kjoGMFqGCAXKUeuADGn5gsxTHcM4NL//D76NrvxAO/jOzfqOdTTaW6rnFuvX2BlbK4 y6kbpg37/XGkJq7MRMEV8LsoBKRsAE8KSe650wEQ0iKzxrQ4yDQ5MAkxRL0JBsRJIA4h BQ6UswpfXKpVfLgLeIoaOxOUD3adbMUt0erH2Y5BHcFkA2EhgrOyhD61H0CpHnWybKg9 9ZmA== X-Gm-Message-State: AE9vXwPtt2Kv+N29NxC7httbisnhMImxH4n8hDn7BjoTpYd/P+o9zXRC4yqKSUSyB8CyDzeRCa/s2s35i8A2eg== X-Received: by 10.159.39.167 with SMTP id b36mr3027271uab.99.1473447791744; Fri, 09 Sep 2016 12:03:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.8 with HTTP; Fri, 9 Sep 2016 12:03:11 -0700 (PDT) From: Kathleen Moriarty Date: Fri, 9 Sep 2016 15:03:11 -0400 Message-ID: To: "ipsec@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [IPsec] AD Review of draft-ietf-ipsecme-safecurves X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 19:03:14 -0000 Hello, Thanks for your work on draft-ietf-ipsecme-safecurves. The draft looks ready to go, I just need to figure out what to do to get the downref into the registry. This has come up before for ed25519 & ed448, so it would be good to get that done. Thanks. -- Best regards, Kathleen From nobody Fri Sep 9 13:01:15 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28DA12B337 for ; Fri, 9 Sep 2016 13:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMixy5wW8gNI for ; Fri, 9 Sep 2016 13:01:12 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20EB412B22C for ; Fri, 9 Sep 2016 13:01:11 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id l131so51445499lfl.2 for ; Fri, 09 Sep 2016 13:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-transfer-encoding:importance; bh=YAymbDkyhSCxu+E/SNxBVG8KhZYgOd+6QSKMPU4UtGQ=; b=sIqXI+hltBn47l8J37rtahshqj64ZIfKeOquPPg0ed5Lc/P5rvpdo4DZzMuHbFDX/d e7A9WbpnwZ13UMhN8dFLi0asInWZjVXJOpk60rxzYvnfIfmCPfV0vouyhmKQcK3el14Z vPM6azfyqSOdonYVCdt7L4I93aUFwX2cvYLt08Zpj9CM50CCWnf1VrgA+QsBORejtpMF f44cI1Crug56WJjqP91V/U12fG2pYslvCzAWtPuOTIL4x8oXFo0yJGYCA724GImP7TCK h0/EPX4N72Dx5OaVwE4qYrwBKzyhteDp+1/Rqm3zmD3taQWLTHZUhVJbCknV1FxnvezS YNYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=YAymbDkyhSCxu+E/SNxBVG8KhZYgOd+6QSKMPU4UtGQ=; b=je7i0zpDfUOuvpRR/Y1Q7zPOJ2bVlYrF+dl2Nx21AphMLlkmSpgWDVZ6TX0PEIO4XZ Wt8G644BtTcbPgDQkdtvhTtubIlvH8O4ho/mrcsJUhqTqc9vZhQwzMsT8/GuIgSV7FhD rWPdjBQv4OAbDO6oH1MKQJv19OzITRp9Lv3yZZc0wtFcd0K7rRTksBpxTQVl65nRcF1N PVJIxOn6fyJhP6G0NdsLl9C3crSvlwdyIu/rqTDOXAKp5WpmpAC4QymnSnqTTJEotFEv ICt3Y6SEoB76GM0h/lP+KyCnrr3b7J5E0QrKmp7rOvMh46E/YfctqMqi6bz3iumeDKvK 92BQ== X-Gm-Message-State: AE9vXwPAzXsQDf6zeaUAcCn9D4TObp/ePtS8jfvYEa/PN/oMfsPL1vrN9g+SnWBPUbrh4g== X-Received: by 10.46.9.13 with SMTP id 13mr1833461ljj.2.1473451269090; Fri, 09 Sep 2016 13:01:09 -0700 (PDT) Received: from chichi (ppp83-237-170-241.pppoe.mtu-net.ru. [83.237.170.241]) by smtp.gmail.com with ESMTPSA id t78sm844834lfi.43.2016.09.09.13.01.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 09 Sep 2016 13:01:08 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Kathleen Moriarty" , References: In-Reply-To: Date: Fri, 9 Sep 2016 23:01:02 +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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ddos-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 20:01:14 -0000 Hi Kathleen, thank you for the review. I'll try to answer. > Hello, > > Thank you for you work on draft-ietf-ipsecme-ddos-protection. This is > a good read that lays out the problem well and describes the solution > well. Thanks for that! > > I have some nits and questions before we put this into IETF last call. > > Section 4.2 - > This level of detail is great. Hopefully developers make sure logs > and other ways to help with troubleshooting to determine the number of > half open SA and failed IKE-Auth exchanges. Are these maintained with > counters (SNMP/YANG) or log entries or some other way? Does this > matter and does it need to be indicated here for developers so > implementors have the tools needed to determine next steps? I think that it is a local matter how implementations measure the number of half-open SAs. It is possible to maintain some counters or parse local log files. Or, for example, just call size() method for some kind of container (list, map) in case all half-open SAs are placed there. The only requirement is that implementations must do this measuring periodically to get a picture of what is happening. Again, it is a local matter how often implementations should learn the number of half-open SAs, the draft doesn't impose any restrictions. Do you think some clarification is needed here? > Section 4.6: Suggest using some descriptive language instead of > saying 'garbage' in the following sentence for non-native English > speakers: > > The > attacker can just send garbage in the IKE_AUTH message forcing the > Responder to perform costly CPU operations to compute SK_* keys. How about: Instead of sending properly formed and encrypted IKE_AUTH message the attacker can just send arbitrary data, forcing the Responder to perform costly CPU operations to compute SK_* keys. (by the way, I'm a non-native English speaker, and the word "garbage" doesn't shock me here, but I agree that more formal language is probably better) > Same in section 4.7, maybe "meaningless bits" or something along those lines? Great! Definitely better from my point of view, thank you. > Malicious > initiators can use this feature to mount a DoS attack on the > responder by providing an URL pointing to a large file possibly > containing garbage. > > Section 7.1.1.2: The following sentence could be cleaned up a bit > (last paragraph): > The > initial request message sent by the Initiator contains an SA payload > with the list of transforms the Initiator supports and is willing to > use in the IKE SA being established. I'm not sure what's wrong with this sentence, but I'll try. Is the followng better? The initial request message sent by the Initiator, contains an SA payload, containing a list of transforms. The Initiator supports all transforms from this list and can use any of them in the IKE SA being established. > Section 7.2.1.1 > > The first sentence of course fits in this section, but has already > been said in the draft. This whole section seems repetitious. There > are a few places where text is repeated, is it possible to reduce > repetition? It might not be for clarity as the sections vary, but an > effort to reduce it might make the latter part of the draft as easy to > read as the start. Yes, this sentence almost duplicates the sentence from the second para of previous Section (7.2). But I'd rather to keep it in 7.2.1.1 and just remove from 7.2, because 7.2.1.1 gives more detailed instructions to implementers while 7.2 is just an overview. Are you OK with this? > Section 7.2.4: 4th paragraph, 1st sentence doesn't read well. Can you > break it up and phase the "non-first" differently? I don't think that > is a term of art, is it? > > If the Initiator uses IKE Fragmentation, then it is possible, that > due to packet loss and/or reordering the Responder could receive non- > first IKE Fragment messages before receiving the first one containing > the PS payload. How about: If the Initiator uses IKE Fragmentation, then it sends all IKE Fragment messages simultaneously. Due to packets loss and/or reordering the Responder could receive subsequent IKE Fragment messages before receiving the first one, that contains the PS payload. Thank you, Valery. > Thank you! > > -- > > Best regards, > Kathleen From nobody Fri Sep 9 13:06:54 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA2812B1EB for ; Fri, 9 Sep 2016 13:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Frec_NuRHU1 for ; Fri, 9 Sep 2016 13:06:50 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B45DF12B189 for ; Fri, 9 Sep 2016 13:06:50 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id z190so78859776qkc.3 for ; Fri, 09 Sep 2016 13:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xLvi0RUHIIB6seuRKqO20+9kNxudzEx53ETXEv6twY4=; b=fv+z106yEPTUBe6BBHbqqqimnk0/NC6SCYngW8IX4knGHOI4sv1pQIvvLIJrjl5ukr 7rs5k5pA6CaUQ77MFW7vnSrycMb0qeZRpgXQIw/m6mv17+Zu/AojuMfXjRQU+2vwdpOi YeiS0l00xP22PPzXy0zJp1gavfNnTR4yS9mtE0IN6G6TQmcgts4m5yXIgZyRJoWouwOC NkQonFgJXBQdjPp+XwN0F911djrvt4c70q6k42MpDN6VhkbrK0a9WdfvsCNPIJhKR1If iuqkjd+uSX+H4HmqMtgk7Qno6FxrOlgxnhRknrIfQwOaDwjHY+U60XjfAz6M4ytKCWPA 7+2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xLvi0RUHIIB6seuRKqO20+9kNxudzEx53ETXEv6twY4=; b=hA7sotJ7iFy9awDKICBcs3YQRjRNYAZm1xr2hEMqFJgpvgab8OvpePMrhJqc7FgOep UzgixzmsN31dPOMue1Sq1lfAOSBCxUB+CqK0gXUvBJi6aWfZ9s5zav8b7rvsJnEUlmKC W9NQY1J0e5G9s2W0jQCNEiFKAc5m3/ajrSiDDtWg++ebEnFnVnaJ4ZdsVHf+pR0ncFXz DOqN/XMoUyjV71oCu2jeENi5JYGalgGNz6ppdkQf5Vdsszmkl9Mswbs+EXZfmG2PIV6j lnDCwFiLAtuaCcXKBQDGaCgsNAMRfV4mdMcIAKEljolkmZ/AhSkkMbp1qt7yk60iaotX b6gA== X-Gm-Message-State: AE9vXwPGHCc/D3nvMml+17KfbFzFVI/B3LhqkblnWZaNdo5kUT2GtaHSzXKpvPR/Jilfog== X-Received: by 10.55.168.78 with SMTP id r75mr6437820qke.19.1473451609904; Fri, 09 Sep 2016 13:06:49 -0700 (PDT) Received: from [192.168.1.3] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id 62sm2998195qtg.14.2016.09.09.13.06.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 09 Sep 2016 13:06:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G36) In-Reply-To: Date: Fri, 9 Sep 2016 16:06:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Valery Smyslov Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ddos-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 20:06:52 -0000 Hi Valery, =20 Thanks for the quick response, inline. Please excuse typos, sent from handheld device=20 > On Sep 9, 2016, at 4:01 PM, Valery Smyslov wrote: >=20 > Hi Kathleen, >=20 > thank you for the review. I'll try to answer. >=20 >> Hello, >> Thank you for you work on draft-ietf-ipsecme-ddos-protection. This is >> a good read that lays out the problem well and describes the solution >> well. Thanks for that! >> I have some nits and questions before we put this into IETF last call. >> Section 4.2 - >> This level of detail is great. Hopefully developers make sure logs >> and other ways to help with troubleshooting to determine the number of >> half open SA and failed IKE-Auth exchanges. Are these maintained with >> counters (SNMP/YANG) or log entries or some other way? Does this >> matter and does it need to be indicated here for developers so >> implementors have the tools needed to determine next steps? >=20 > I think that it is a local matter how implementations measure the number o= f half-open SAs. It is possible to maintain some counters or parse local log= files. Or, for example, just call size() method > for some kind of container (list, map) in case all half-open SAs are place= d there. >=20 > The only requirement is that implementations must do this measuring > periodically to get a picture of what is happening. Again, it is a local m= atter how often implementations should learn the number of half-open SAs, th= e draft doesn't impose any restrictions. >=20 > Do you think some clarification is needed here? >=20 No, it's fine to leave it out. I appreciate the explanation. >> Section 4.6: Suggest using some descriptive language instead of >> saying 'garbage' in the following sentence for non-native English >> speakers: >> The >> attacker can just send garbage in the IKE_AUTH message forcing the >> Responder to perform costly CPU operations to compute SK_* keys. >=20 > How about: >=20 > Instead of sending properly formed and encrypted IKE_AUTH message the > attacker can just send arbitrary data, forcing the Responder to perfo= rm costly CPU operations to compute SK_* keys. > (by the way, I'm a non-native English speaker, and the word "garbage" > doesn't shock me here, but I agree that more formal language is probably b= etter) >=20 >> Same in section 4.7, maybe "meaningless bits" or something along those li= nes? >=20 > Great! Definitely better from my point of view, thank you. Thank you! >=20 >> Malicious >> initiators can use this feature to mount a DoS attack on the >> responder by providing an URL pointing to a large file possibly >> containing garbage. >> Section 7.1.1.2: The following sentence could be cleaned up a bit >> (last paragraph): >> The >> initial request message sent by the Initiator contains an SA payload >> with the list of transforms the Initiator supports and is willing to >> use in the IKE SA being established. >=20 > I'm not sure what's wrong with this sentence, but I'll try. Is the follown= g better? >=20 > The > initial request message sent by the Initiator, contains an SA payload, > containing a list of transforms. The Initiator supports all transforms > from this list and can use any of them in the IKE SA being established. Yes, thank you! >=20 >> Section 7.2.1.1 >> The first sentence of course fits in this section, but has already >> been said in the draft. This whole section seems repetitious. There >> are a few places where text is repeated, is it possible to reduce >> repetition? It might not be for clarity as the sections vary, but an >> effort to reduce it might make the latter part of the draft as easy to >> read as the start. >=20 > Yes, this sentence almost duplicates the sentence from the second para > of previous Section (7.2). But I'd rather to keep it in 7.2.1.1 and just > remove from 7.2, because 7.2.1.1 gives more detailed instructions > to implementers while 7.2 is just an overview. >=20 > Are you OK with this? Yes, thank you! >=20 >> Section 7.2.4: 4th paragraph, 1st sentence doesn't read well. Can you >> break it up and phase the "non-first" differently? I don't think that >> is a term of art, is it? >> If the Initiator uses IKE Fragmentation, then it is possible, that >> due to packet loss and/or reordering the Responder could receive non- >> first IKE Fragment messages before receiving the first one containing >> the PS payload. >=20 > How about: >=20 > If the Initiator uses IKE Fragmentation, then it sends all IKE Fragment m= essages simultaneously. > Due to packets loss and/or reordering the Responder could receive subse= quent IKE Fragment messages before receiving the first one, that contains t= he PS payload. Better, thanks! Let me know when you have the updated draft & I'll initiate= IETF last call. Thanks, Kathleen=20 >=20 > Thank you, > Valery. >=20 >> Thank you! >> --=20 >> Best regards, >> Kathleen >=20 From nobody Fri Sep 9 14:30:26 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B4812B40F; Fri, 9 Sep 2016 14:30:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.32.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147345662215.30852.10925244498590101543.idtracker@ietfa.amsl.com> Date: Fri, 09 Sep 2016 14:30:22 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-mglt-ipsecme-rfc7321bis-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 21:30:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Authors : Daniel Migault John Mattsson Paul Wouters Yoav Nir Tero Kivinen Filename : draft-mglt-ipsecme-rfc7321bis-04.txt Pages : 13 Date : 2016-09-09 Abstract: This document updates the Cryptographic Algorithm Implementation Requirements for ESP and AH. The goal of these document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. This document obsoletes RFC 7321 on the cryptographic recommendations only. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-rfc7321bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-mglt-ipsecme-rfc7321bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-mglt-ipsecme-rfc7321bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 12 02:00:18 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA8C12B1B6; Mon, 12 Sep 2016 02:00:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.32.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147367081810.14564.14875900515649411077.idtracker@ietfa.amsl.com> Date: Mon, 12 Sep 2016 02:00:18 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-09.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 09:00:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks Authors : Yoav Nir Valery Smyslov Filename : draft-ietf-ipsecme-ddos-protection-09.txt Pages : 29 Date : 2016-09-12 Abstract: This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) 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: https://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ddos-protection-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 12 04:25:52 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7BD12B0C6 for ; Mon, 12 Sep 2016 04:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwbivZhzoECR for ; Mon, 12 Sep 2016 04:25:50 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5CAF12B0B6 for ; Mon, 12 Sep 2016 04:25:49 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id l131so84335189lfl.2 for ; Mon, 12 Sep 2016 04:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=PVQ9KnW7hNga9MzEqtfjDE7QJqqXwTeGogZz1YAsSoE=; b=ps9v08kJL0gxgjRs41VgY19YaT33dOEOJnl2+rdOF7tUsxEQuRGkzhZWskQ5k3SnRp VLJeThbjn+OVlE4K7cBNl+GO2r5Mk+b++ku5mL5tTJswc9P+0qNjhEUzi1PrFT16jwga 6D1fG/4SCquukc3hFAwMtDRroIt9vl80zd1e7eK8t9bDMuikA3KkhDTTMmGkcQIO3PjE B0VoN1rTBmlNlyzwE9tq5XPScCGKPKkIuuqVJOzmKgjKp7SytQu7TXa+Gk9+EHiLgH8D XLlyTrNdxDvXQwC2wT36/mGG7Fucu3i8P4KqYCBVqo9Il7TLQgK5zUHK77ptJhCva14T 3hgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=PVQ9KnW7hNga9MzEqtfjDE7QJqqXwTeGogZz1YAsSoE=; b=ALQo4vraYB2Flb43JfSsOdfg531zyhGMkyejvRTlh1aJBSElMQkAgtj9q9RcP+dZaV DWMVKj8SYmOS2Swt54MW1+YAmEDR0TtiMIiXAFfOiWav/O5wInhI+cXi5mtetM5g4/+9 BtFqXLRXgzqUPnXGgopVqWOX0WFTbMaKiJVKQs623JOixL4swjDImHcOziZw+BOpaQQc bAWVkN3Gv/4SCS8oEg5KBQ7fYNt2YBVVjFpnv0zYweHk7cDca6V7qD5swUea74jP5dRt 9QEU1SiQk1TMyWINw3nMVf20d1SG7Q6jbN0vNYfSNVxH7NOy81o4QK7M/GJ01StXCt3C sZEA== X-Gm-Message-State: AE9vXwMi3BHTLWkEQV7YK/MYCv/yiJeoqQS73j0WW21uz3v6Y0yScpFRSpvnmnFHO8YrIQ== X-Received: by 10.25.215.82 with SMTP id o79mr5570418lfg.132.1473679547831; Mon, 12 Sep 2016 04:25:47 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 137sm185205ljj.47.2016.09.12.04.25.46 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Mon, 12 Sep 2016 04:25:47 -0700 (PDT) Message-ID: <5C5029305BCB44E884B58F03462D5266@buildpc> From: "Valery Smyslov" To: References: <147367081810.14564.14875900515649411077.idtracker@ietfa.amsl.com> Date: Mon, 12 Sep 2016 14:25:44 +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: Cc: Kathleen Moriarty Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-09.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 11:25:51 -0000 Hi, a new version of the draft is published. It includes text changes suggested by Kathleen. Regards, Valery & Yoav. > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and Extensions of the IETF. > > Title : Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed > Denial of Service Attacks > Authors : Yoav Nir > Valery Smyslov > Filename : draft-ietf-ipsecme-ddos-protection-09.txt > Pages : 29 > Date : 2016-09-12 > > Abstract: > This document recommends implementation and configuration best > practices for Internet Key Exchange Protocol version 2 (IKEv2) > 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: > https://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ddos-protection-09 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Sep 12 08:11:44 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 370F112B41B; Mon, 12 Sep 2016 08:11:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147369310221.8985.17250539577210381092.idtracker@ietfa.amsl.com> Date: Mon, 12 Sep 2016 08:11:42 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-13.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 15:11:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Algorithm Implementation Requirements and Usage Guidance for IKEv2 Authors : Yoav Nir Tero Kivinen Paul Wouters Daniel Migault Filename : draft-ietf-ipsecme-rfc4307bis-13.txt Pages : 18 Date : 2016-09-12 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updates RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 12 09:34:52 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9EA12B2CD for ; Mon, 12 Sep 2016 09:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZvoyJzvig_W for ; Mon, 12 Sep 2016 09:34:45 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF35612B376 for ; Mon, 12 Sep 2016 09:23:43 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id 16so122874157vko.2 for ; Mon, 12 Sep 2016 09:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=sletQRN59w+4pfB6ukThvYakL9SEHcFngQiIJdH/nd4=; b=p8qy1WSSVbFw0lwPH9gfXG4uKrwLuJw4yfd9bu644C3nXwlBOmICAV8XxiggcP9ule W6cXX4amCk8tAApEVscVWIedW9vIqdmuqXQFSI/RYakMcg8xNBdLW0D/VSZ8WBbe24oz 5Pth0hjTGxlEhe02c1CFlEY2KCOmCpeH7mJVkLhP52h6dDJr4197O6B0wzESiJk/tx/z wL98/7bEH14g0kKNr2A0dVkgBJOLmu5rPA4S2QsTBgt0XbPriJEqtgjKtZh0qkq6lG2b 9DXor+2t64SofEQ4IUXx56HQawH+RpsJpu8ZrjsZUlAzGvJtUSD4XKNbAQBPaZ9Mv06l 97zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=sletQRN59w+4pfB6ukThvYakL9SEHcFngQiIJdH/nd4=; b=EU8WY3xGyfB6mzDANFrPpFJNKT+4rYWYHxgyAFwmUFGAtpwwhRkpcLCghv8U4wk2k7 Tsdi4JIJAGagWdmL8z5KrVzhjeLKt5rKQWEtX1AexU5XyZF1/rqp0mhX55dQEdOUGHh/ cR2yJIh/rKlZZvVO8GvuWRw8HDURHqe8bFKPHVDOMpm/b26qjxKgleUsb9k3VRUjWHXP LM5wx9XCkwnt8a/PD1NebmReSo0CwzT568rN1+414LVpzE6DbtuOQt352QrZqy+9/Ie9 kUUrGV2AxKZyRvNra3mdW4+vPBILNehV2abQsG86swlg2uCFKvJE47mxa8jASCX5+P5A Zs/g== X-Gm-Message-State: AE9vXwPqQ9jx/ZG8xZg5ad33OI3PPJgg0J8z0wbS17aMNf3QrueeROy3uMh+/SiovcS6+HvfdgbtSl6GtmsecA== X-Received: by 10.31.221.3 with SMTP id u3mr12781451vkg.25.1473697422160; Mon, 12 Sep 2016 09:23:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.8 with HTTP; Mon, 12 Sep 2016 09:23:41 -0700 (PDT) In-Reply-To: References: From: Kathleen Moriarty Date: Mon, 12 Sep 2016 12:23:41 -0400 Message-ID: To: "ipsec@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [IPsec] AD Review of draft-ietf-ipsecme-safecurves X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 16:34:51 -0000 Hello, FYI - I added the downref for RFC7748 to the registry from another draft that I just processed with the same downref. Thanks, Kathleen On Fri, Sep 9, 2016 at 3:03 PM, Kathleen Moriarty wrote: > Hello, > > > Thanks for your work on draft-ietf-ipsecme-safecurves. The draft > looks ready to go, I just need to figure out what to do to get the > downref into the registry. This has come up before for ed25519 & > ed448, so it would be good to get that done. > > Thanks. > > -- > > Best regards, > Kathleen -- Best regards, Kathleen From nobody Tue Sep 13 05:34:50 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BF212B39C for ; Tue, 13 Sep 2016 05:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZPifFSmc4ME for ; Tue, 13 Sep 2016 05:34:46 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 787F812B396 for ; Tue, 13 Sep 2016 05:34:43 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id u14so108813030lfd.1 for ; Tue, 13 Sep 2016 05:34:43 -0700 (PDT) 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-transfer-encoding; bh=Mh+osDW5AwYZzKjfxz1HZaPamn6H5bw1b/bFjR+adcU=; b=M0OE0yp41SFqpNjKXjJAKOzFQJhyAQdB1pjcZcekPy3ORRNW0Cm0bKoWZsU253SgOo D5jdC1gJBcyvbpa/331rtH17GIaCStrH+9n/b76bjX9nIwAUnAAF5q31Kp1hFtQx7Trd eCcp2A2W/I4n1ixNTu5kAqQJfRFRqHT2pJqscHTY9M5Es9HvO96hOROqQo2c5ZYrfs6+ AnL9L4LMWMXo68FOqxMqPjhUUxX4bvOsQ3aQTSJGyzPBK8lx+1pDKnKCMWSwJphwmsIu zzdquV+nFg/6lWSNL8JKfpSTo0mx9sczNzmfk0zu+gAElTMv6dEUCNxhuU6ZZGceKjl6 Vz8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version:content-transfer-encoding; bh=Mh+osDW5AwYZzKjfxz1HZaPamn6H5bw1b/bFjR+adcU=; b=DIuq465267re2so9IUlzGyqV1oHlvnyeb+KoZjdkBxYmYiDZkfp18KLVnLlBv1KXp6 P6YsvjADBTegth0n1S5FJhRcNvxVcBujITBVF6JM0BGQongc5ziv7HjtmuIR/bSGTqbR VQw2nDDTon1GSLJuDms/ZBD/DiTtIbnp1MnTeCuc7vHSUNEBJokBHWkF02vLvIVoW3EB 4dWLVxUbj5eOGr0bDFeE0CUf2wZ+FKW9J7Rf9nbVPHDolTcKh08+FDsepHSQzj0c7lfJ hHHJYsljJ5Y14NRflO5y3nJTiSHuxnDlcf2ZD6T1w14JHXiELx1q6+nzpT9MuT8jEnAJ m2vg== X-Gm-Message-State: AE9vXwN2zCllboPcg2bqxwWbwUIM6ltEeclzbR1ok/kQpGrpWIC3pVHu/LMIsuPubiN+xA== X-Received: by 10.25.39.15 with SMTP id n15mr7521427lfn.91.1473770081190; Tue, 13 Sep 2016 05:34:41 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 184sm3934363lfz.22.2016.09.13.05.34.40 for (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Tue, 13 Sep 2016 05:34:40 -0700 (PDT) Message-ID: <08AB2EF60E5C4A9C8950483676619B4C@buildpc> From: "Valery Smyslov" To: "IPsecME WG" References: Date: Tue, 13 Sep 2016 15:34:35 +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: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-rfc4307bis-11 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 12:34:49 -0000 Hi, here is my review of draft-ietf-ipsecme-rfc4307bis-13. I didn't participate in the recent discussions, so I'm acting here more or less like "fresh" reader. Overall, I think that the document is in a good shape, however some additional polishing is required to improve its clarity and eliminate possible sources of confusion. Section 3.1 It is not clear from the table and subsequent comments what key length for AES corresponds to what requirement levels. Well, it is clear, that 192-bit AES is MAY, however I'm a bit confused abouth other key lengthes. Does the comment (1) mean that both AES-128-CBC and AES-256-CBC are MUST and both AES-128-GCM_16 and AES-256-GCM_16 are SHOULD? Could it be made more clear, e.g. by including key length in the table? And the comment (IoT) brings even more confusion. It states that "only 128-bit keys are at MUST level", while the line it refers to (ENCR_AES_CCM_8) indicates SHOULD level. Well, I guess that the text means that only AES-128-CCM_8 is SHOULD, while other key lengthes are MAY, but the current text is really confusing (yes, it is explained below in one of subsequent paras, but I still prefer to have more clear statement). I'd again suggest to add key length into the table so that it is indicated explicitely. The next para after the table is inaccurate. It states: ENCR_AES_CBC is raised from SHOULD+ in [RFC4307] to MUST. It is the only shared mandatory-to-implement algorithm with RFC4307 and as a result it is necessary for interoperability with IKEv2 implementation compatible with RFC4307. However, it is not exactly true. The comment (1) indicates that both AES-128-CBC and AEC-256-CBC are now MUST, while in RFC4307 AES-256-CBC wasn't mentioned at all, so it definitely wasn't SHOULD+. So, this statement is true for AES-128-CBC and not true for AES-256-CBC. Section 3.2 If an algorithm is selected as the integrity algorithm, it SHOULD also be used as the PRF. That requirement isn't clear for me. Where it comes from? How it is justified? Is the document in the position to make such restrictive requirement? Isn't it a local policy matter? PRF_HMAC_SHA1 has been downgraded from MUST in RFC4307 to MUST- as their is an industry-wide trend to deprecate its usage. I think some more reasons should be given besides "an industry-wide trend". Industry usually follows standards, so it's a bit silly to refer to industry trends as a reason here. I think some words about current concerns in the security of SHA1 should be added (like for PRF_HMAC_MD5 below). Section 3.3 AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC4307 to MUST- as there is an industry-wide trend to deprecate its usage. See my comment above to the similar sentence in Section 3.2 Section 4.2 | RSASSA-PSS with Empty Parameters | MUST NOT | | | RSASSA-PSS with Default Parameters | MUST NOT | | Well, I'm a confused with these requirements. As far as I understand the RSASSA-PSS parameters default to using a SHA1 for both hashAlgorithm and maskGenAlgorithm. Isn't more clear for readers to include | RSASSA-PSS with SHA1 | MUST NOT | | instead of these two lines, which in their current form don't explicitely refer to any cryptographic algorithm and force reader to dig into RSASSA-PSS specification to just get know that it was SHA1 meant? Or did I miss something? Minor/editorial issues. Abstract: This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). I think AH must also be mentioned here (as RFC 7321 defines algorithms for both). Section 3.1 Algorithms that are not AEAD MUST be used in conjunction with an integrity algorithms in Section 3.3. should be: Algorithms that are not AEAD MUST be used in conjunction with integrity algorithms described in Section 3.3. In the sentence It has been recommended by the CRFG and others as an alternative to AES-CBC and AES-GCM. What "others" mean? Isn't it too vague wording for Standards Track RFC? Either list these "others" (at least some of them) or remove reference to them. Section 3.2 PRF_HMAC_SHA2_256 was not mentioned in RFC4307, as no SHA2 based transforms were mentioned. This sentence makes little sence for me. Shouldn't second "mentioned" be "defined at that time"? Later: PRF_HMAC_SHA2_256 MUST be implemented in order to replace SHA1 and PRF_HMAC_SHA1. We are talking about PRFs here, so why SHA1 is mentioned? If you are talking about general desire to get rid of SHA1-based transforms, then the sentence should be more explicit abot that. Section 3.3 AUTH_HMAC_SHA2_256_128 was not mentioned in RFC4307, as no SHA2 based transforms were mentioned. See my comment above about similar sentence in Section 3.2 AUTH_AES-XCBC is only recommended in the scope of IoT, as Internet of Things deployments tend to prefer AES based pseudo-random functions in order to avoid implementing SHA2. s/AUTH_AES-XCBC/AUTH_AES-XCBC_96 (as in IANA Registry) Section 3.4 Group 19 or 256-bit random ECP group was not specified in RFC4307, as this group were not specified at that time. See my comment above about similar sentence in Section 3.2 Regards, Valery. From nobody Tue Sep 13 07:57:45 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFC312B3B3 for ; Tue, 13 Sep 2016 07:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNb1T34dSv04 for ; Tue, 13 Sep 2016 07:57:42 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0139.outbound.protection.outlook.com [23.103.200.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1DB12B42F for ; Tue, 13 Sep 2016 07:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rN6cAGrUkCJj3dRBbNNARM7sM5IG0zXAbDx5pMkS5NY=; b=ZHxkCGqFoxlpH4wIglVUPMyuQiXHayHru1vbpiBc2nBSj0mhWxpy4c59zdpj3cyL2zp0JJobi7fhFP4XPmtnvGbt4uq7diOU4MSxLaVyRICDqSpQGPZWZyehTy2vjrXZbzqjTbMGDcN+u2c+wIAEur6ERQ2owLScvB18BERQLB0= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1437.namprd09.prod.outlook.com (10.173.50.11) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.10; Tue, 13 Sep 2016 14:31:02 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0619.011; Tue, 13 Sep 2016 14:31:02 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: Call for adoption of draft-mglt-ipsecme-rfc7321bis as an IPSecME WG document Thread-Index: AdIFiu5YSsRPKyt0RkS9hutYx8w6egIP/IRA Date: Tue, 13 Sep 2016 14:31:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: 67f22a9b-9330-41b8-1481-08d3dbe2968a x-microsoft-exchange-diagnostics: 1; MWHPR09MB1437; 6:m9muWnhp/SYJbYruHuk+pU848ZoXL3KmZFYeEd+gUGwXmOwZC/tdE8mS403AtDLL1cAUIYrUg1YNd+RCdGyrpiUw5j/7qTBNUWga1fcDy0lvF/viWDmPYEfJMWixsR3JMOLn1X80dNw1yxVA24G4Q0PPeQ8RLfV3p/pL9DJWTu7faO2FRQjhPhJT1ai5SAOF7ZJ9gYIHQwhwoZSQpkYlfzFWxj0lsXVfW3qOafiF53Dh3BpR/qUE0slJjx8Zvqv/+lNd6oisyRkX/DDpQVNp6rWE6qBxd5GvqZww9kysRVJHULpKHuWNYov5mvtoYslvbhuh6t1iZj8nVhttmEEMbw==; 5:GBKCmMMUN+GB73DxvGGOCELaLlqZ4pfSDLu4O6YzbYyWoIsR6yEW0lxQ2bdYlOgAduugn/qMp+7aV8DxHzTsroulCpO4pm86Qtte02qEkndh72gPqrcIJBsMTfI/czlEaSgyXt92GvHVzB3+ZohgwA==; 24:0RrBMp9jRRs6AG7Uve6gTnAj/W0KKImyVaprq+exzSjANFavrvWEQW0luSUDA7dHl3H/vcybfS0Qtq3nioyAJwTP7j0scUB8o+4PU9j1xrA=; 7:OC4ABPqp66gjwpAsqc4ovU7iFYZ5flvqwA7aWt7ONsFiU18LQzYeocGZF1Zfoqo5ZFKG4RXMlUMNxeSmc016qHd56if6C3ruvjJB3MADuZLThaz9AP+aW5aUCiye41x2WcKKHpxi9S/zojRQm8H74rUL/yNPFgAadzFgNKylbHjxLl3ia99vcTnNkIso8gMWq7CA3koWP2e1KN+x+RDAHE3me83cI45Z8MVHTD1Vv6A1+6eiRsrM/2karmY/c0Yn x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR09MB1437; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:MWHPR09MB1437; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1437; x-forefront-prvs: 0064B3273C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(189002)(199003)(377454003)(101416001)(97736004)(99286002)(107886002)(106356001)(33656002)(189998001)(105586002)(76176999)(54356999)(7696004)(5002640100001)(50986999)(2950100001)(77096005)(15975445007)(86362001)(2900100001)(66066001)(450100001)(11100500001)(122556002)(8936002)(5660300001)(3900700001)(7736002)(230783001)(7846002)(81156014)(76576001)(305945005)(8676002)(81166006)(2906002)(10400500002)(9686002)(3280700002)(68736007)(6116002)(110136003)(3660700001)(586003)(19580405001)(87936001)(3846002)(74316002)(92566002)(19580395003)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1437; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2016 14:31:02.1543 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1437 Archived-At: Subject: Re: [IPsec] Call for adoption of draft-mglt-ipsecme-rfc7321bis as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 14:57:44 -0000 This is a quick reminder that the call for WG adoption on draft-mglt-ipsecm= e-rfc7321bis ends on Wednesday, September 14th, 2016 at UTC 23:59. I have not seen any support or concerns posted in response to my initial em= ail. While this document has received support in past meetings and discussi= on, it is important to see that support reflected in this adoption call. Pl= ease respond indicating your support or concerns regarding WG adoption of t= his draft. Thanks, Dave > -----Original Message----- > From: Waltermire, David A. (Fed) > Sent: Friday, September 02, 2016 10:33 PM > To: IPsecME WG > Subject: Call for adoption of draft-mglt-ipsecme-rfc7321bis as an IPSecME > WG document >=20 > This is the call for adoption of https://datatracker.ietf.org/doc/draft-m= glt- > ipsecme-rfc7321bis/ as an IPSecME working group (WG) document. >=20 > By adopting this draft, the WG is agreeing to take this on as an official= WG > item to continue work on the draft. Please reply to this message with any > comments supporting or concerns against adopting this draft. This call wi= ll run > until Wednesday, September 14th, 2016 UTC 23:59. >=20 > Thanks, > Dave and Tero From nobody Tue Sep 13 08:44:14 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F26712B51E for ; Tue, 13 Sep 2016 08:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dA7Eaxy3_b7 for ; Tue, 13 Sep 2016 08:44:08 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548F812B723 for ; Tue, 13 Sep 2016 08:11:03 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id l131so112615540lfl.2 for ; Tue, 13 Sep 2016 08:11:03 -0700 (PDT) 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-transfer-encoding; bh=pwoWl3GfQkVe/Y8PbB+TlUSCzkvIk2qN68VsrcGem5s=; b=hVnzCGji1yU853H0voc2i24u4WY4x+wFzy8FDhRjQMFIJjvrLbTvXLBpuKGURdbytN +k9vMq6AK0/Nwh3b4zEnFXgoym3xIU2mgDvsssIqyvcltxTdATK9EpAk4JxrkllFtO4l bsb+E255AIjBV8d/THoaTI2GFIzRaze0T8mx2U4q5YSqztOmaAbInev9CMUsNz+UwBqb 5X14E0FaVbpC2P3lzQwf6upG+eTyrf9SFSKaajB58tf5xRE+YSHs/G6mcLSAAf3nkf3+ a/Dk6vmYj/OAHZQnTGc/MQWuj1GYhPDRlFkzik76P5wlsh+AF9Alhv6rGFHi3X6kewgp WwRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version:content-transfer-encoding; bh=pwoWl3GfQkVe/Y8PbB+TlUSCzkvIk2qN68VsrcGem5s=; b=OoN6H5/E3HlS0msWAvzwG4g+gORGlLDvxBL4FfT3F7V9doU6Pp0BCGx1C9gbH4NPuW 651jU53pbSM7mHoWXcFSBSetQMLQDeH+4D+uX99dhUeglBA/4UOwq0toQWO0oNgtfWaa Uq9B1NGFOZiuWbIxnLMHNnuN6TpIiFS2myxeXu3fixdIE4EWjRG4hnn908ztjMNetP3W mf7NZ61u57bVLEdX0l2Fk8BafpZBcmPgG9DIvixTWvnESbvqCLpDwQw0N7gArBnDNyed OPgAacv5N/twAjB7hOzUG97n4mQ2K8qg+CMJaLtB1gVb6f5Do62VCv9ktO9IhuY+ZEMP yDHg== X-Gm-Message-State: AE9vXwMVOOP8Hx1K+tvKm5Akx4gCehJGJDXHPW8RdhPsxcnQLlq6/p4j0BqJ6jo7O3pT3Q== X-Received: by 10.46.1.137 with SMTP id f9mr8009150lji.41.1473779461309; Tue, 13 Sep 2016 08:11:01 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 22sm1381107ljj.2.2016.09.13.08.11.00 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Tue, 13 Sep 2016 08:11:00 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Waltermire, David A. \(Fed\)" , "IPsecME WG" References: Date: Tue, 13 Sep 2016 18:10:56 +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: Subject: Re: [IPsec] Call for adoption of draft-mglt-ipsecme-rfc7321bis as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 15:44:12 -0000 Hi, I support adoption of this document. Regards, Valery. > This is a quick reminder that the call for WG adoption on draft-mglt-ipsecme-rfc7321bis ends on Wednesday, September > 14th, 2016 at UTC 23:59. > > I have not seen any support or concerns posted in response to my initial email. While this document has received > support in past meetings and discussion, it is important to see that support reflected in this adoption call. Please > respond indicating your support or concerns regarding WG adoption of this draft. > > Thanks, > Dave > >> -----Original Message----- >> From: Waltermire, David A. (Fed) >> Sent: Friday, September 02, 2016 10:33 PM >> To: IPsecME WG >> Subject: Call for adoption of draft-mglt-ipsecme-rfc7321bis as an IPSecME >> WG document >> >> This is the call for adoption of https://datatracker.ietf.org/doc/draft-mglt- >> ipsecme-rfc7321bis/ as an IPSecME working group (WG) document. >> >> By adopting this draft, the WG is agreeing to take this on as an official WG >> item to continue work on the draft. Please reply to this message with any >> comments supporting or concerns against adopting this draft. This call will run >> until Wednesday, September 14th, 2016 UTC 23:59. >> >> Thanks, >> Dave and Tero > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Sep 13 09:17:12 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D5712B460 for ; Tue, 13 Sep 2016 09:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 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=-1.508] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlqvRAsUfc5R for ; Tue, 13 Sep 2016 09:16:57 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A3112B6F4 for ; Tue, 13 Sep 2016 08:51:31 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sYTgN57Fsz3xJ; Tue, 13 Sep 2016 17:51:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1473781888; bh=/iTlFpOdCJjdI9HptauVnfligLrLjoxwsqJZCP8+4W8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DQRPh/G3bkuuSeHLNnhGLWVxZ9u+9Bzbm0mxXxdkvLHHAOUsUdTcTHgU4HYihtsQR 5VIbaaRYWp8V25G2gkjFtv5xe6BBKSgTDHUyz1Ow8w5PNkYxlja/1SV4t31L7JPrUd PuSE/8mvIfs0JVowsTGXOxYMLE9meHV8S8rN2gwA= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id q1xjMhcl6utz; Tue, 13 Sep 2016 17:51:26 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 13 Sep 2016 17:51:26 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 381EC48171C; Tue, 13 Sep 2016 11:51:25 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 381EC48171C Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2F21240D3594; Tue, 13 Sep 2016 11:51:25 -0400 (EDT) Date: Tue, 13 Sep 2016 11:51:24 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: <08AB2EF60E5C4A9C8950483676619B4C@buildpc> Message-ID: References: <08AB2EF60E5C4A9C8950483676619B4C@buildpc> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-rfc4307bis-11 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 16:17:07 -0000 On Tue, 13 Sep 2016, Valery Smyslov wrote: > here is my review of draft-ietf-ipsecme-rfc4307bis-13. > I didn't participate in the recent discussions, > so I'm acting here more or less like "fresh" reader. Thanks for the review! > Overall, I think that the document is in a good shape, however some > additional polishing is required to improve its clarity and eliminate > possible sources of confusion. > > > Section 3.1 > > It is not clear from the table and subsequent comments what key length > for AES corresponds to what requirement levels. Well, it is clear, that > 192-bit AES is MAY, however I'm a bit confused abouth other key lengthes. > Does the comment (1) mean that both AES-128-CBC and AES-256-CBC are MUST Yes. > and both AES-128-GCM_16 and AES-256-GCM_16 are SHOULD? Yes. > Could it be made more clear, e.g. by including key length in the table? We have kept key lengths out of the tables on purpose. It matches the tables at IANA that also do not list separate items for different key lengths. Would "This requirement" instead of "This requirement level" make that more clear? > And the comment (IoT) brings even more confusion. It states that > "only 128-bit keys are at MUST level", while the line it refers to > (ENCR_AES_CCM_8) indicates SHOULD level. That is an error. It should read "only 128-bit keys are at the SHOULD level" Note that I was hoping the (1) and (IoT) comments would appear similarly indented so it becomes a little more clear and was planning to ask the RFC Editor to ensure that. > The next para after the table is inaccurate. It states: > > ENCR_AES_CBC is raised from SHOULD+ in [RFC4307] to MUST. It is the > only shared mandatory-to-implement algorithm with RFC4307 and as a > result it is necessary for interoperability with IKEv2 implementation > compatible with RFC4307. > > However, it is not exactly true. The comment (1) indicates that both > AES-128-CBC and AEC-256-CBC are now MUST, while in RFC4307 AES-256-CBC wasn't > mentioned at all, so it definitely wasn't SHOULD+. > So, this statement is true for AES-128-CBC and not true for AES-256-CBC. It is only because you do not want to see ENCR_AES_CBC without a key size. We are talking about updating IANA entries, and the IANA entries are not separate for keysize. > Section 3.2 > > If an algorithm is selected as the integrity algorithm, it SHOULD > also be used as the PRF. > > That requirement isn't clear for me. Where it comes from? > How it is justified? Is the document in the position to make such restrictive > requirement? Isn't it a local policy matter? It came from me, after having talked to Tero about a TAHI test suite test case. From what I understand from Tero, historically it was not mandated in the IKEv2 RFC to use the same algorithm, although there is really no argument in favour of using two different algorithms. If the algo is good enough for INTEG, it is good enough for PRF. If one algo is not good enough for either INTEG or PRF, then it is also not good enough for the other. Our implementation does not allow one to specify a PRF different from INTEG (unless INTEG is AUTH_NONE with an AEAD ENCR) I believe we ended up on SHOULD instead of MUST so this could be seen as advise, and not a hard requirement. So it does not update the IKEv2 core RFC in that respect. Do you have any use case where it makes sense that PRF != INTEG ? > PRF_HMAC_SHA1 has been downgraded from MUST in RFC4307 to MUST- as > their is an industry-wide trend to deprecate its usage. > > I think some more reasons should be given besides "an industry-wide trend". > Industry usually follows standards, so it's a bit silly to refer to industry > trends > as a reason here. I think some words about current concerns in the security > of SHA1 should be added (like for PRF_HMAC_MD5 below). How about: "as cryptographic attacks against SHA1 are increasing, resulting in an industry-wide trend to deprecate its usage" > > Section 3.3 > > AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC4307 to MUST- > as there is an industry-wide trend to deprecate its usage. > > See my comment above to the similar sentence in Section 3.2 Same. > Section 4.2 > > | RSASSA-PSS with Empty Parameters | MUST NOT | | > | RSASSA-PSS with Default Parameters | MUST NOT | | > > Well, I'm a confused with these requirements. > As far as I understand the RSASSA-PSS parameters default to using a SHA1 for > both hashAlgorithm and maskGenAlgorithm. > Isn't more clear for readers to include > > | RSASSA-PSS with SHA1 | MUST NOT | | > > instead of these two lines, which in their current form don't > explicitely refer to any cryptographic algorithm and force > reader to dig into RSASSA-PSS specification to just get > know that it was SHA1 meant? Or did I miss something? I'll leave this one to Tero. > Minor/editorial issues. > > Abstract: > > This > document does not update the algorithms used for packet encryption > using IPsec Encapsulated Security Payload (ESP). > > I think AH must also be mentioned here (as RFC 7321 defines algorithms for > both). Agreed. > Section 3.1 > > Algorithms that are not AEAD MUST be used in conjunction with an > integrity algorithms in Section 3.3. > > should be: > > Algorithms that are not AEAD MUST be used in conjunction with > integrity algorithms described in Section 3.3. Agreed. > In the sentence > > It has been recommended by the CRFG and others as an > alternative to AES-CBC and AES-GCM. > > What "others" mean? Isn't it too vague wording for Standards Track RFC? > Either list these "others" (at least some of them) or remove reference to > them. Agreed. I will propose removing "and others". > Section 3.2 > > PRF_HMAC_SHA2_256 was not mentioned in RFC4307, as no SHA2 based > transforms were mentioned. > > This sentence makes little sence for me. Shouldn't second "mentioned" be > "defined at that time"? They might have been defined, but what matters is that the document did not reference them. Perhaps: As no SHA2 based transforms were referenced in RFC4307, PRF_HMAC_SHA2_256 was not mentioned in RFC4307. > Later: > > PRF_HMAC_SHA2_256 MUST be implemented in > order to replace SHA1 and PRF_HMAC_SHA1. > > We are talking about PRFs here, so why SHA1 is mentioned? > If you are talking about general desire to get rid of SHA1-based > transforms, then the sentence should be more explicit abot that. Agreed, it should just be omitted. > Section 3.3 > > AUTH_HMAC_SHA2_256_128 was not mentioned in RFC4307, as no SHA2 based > transforms were mentioned. > > See my comment above about similar sentence in Section 3.2 Same as above. > > AUTH_AES-XCBC is only recommended in the scope of IoT, as Internet of > Things deployments tend to prefer AES based pseudo-random functions > in order to avoid implementing SHA2. > > s/AUTH_AES-XCBC/AUTH_AES-XCBC_96 (as in IANA Registry) Actually, we should add this to section 9 for renaming and call it AUTH_AES_XCBC_96. > Section 3.4 > > Group 19 or 256-bit random ECP group was not specified in RFC4307, as > this group were not specified at that time. > > > See my comment above about similar sentence in Section 3.2 The second "specified" here could be changed to "define" ? Paul From nobody Tue Sep 13 11:56:25 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6ECF12B025 for ; Tue, 13 Sep 2016 11:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kekh5ELWsYJd for ; Tue, 13 Sep 2016 11:56:22 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C28E12B4E0 for ; Tue, 13 Sep 2016 11:56:19 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id h127so117522216lfh.0 for ; Tue, 13 Sep 2016 11:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=+wjEKjuSjyyTvniJ7+xgKOkW9e9BIcHlbOCG8zFLtfA=; b=rQRY1vlcXDN+4ddiTfpLGnpIjLJXYIszLweQclugGFU3dXWyUe5sGjtQTQg9EkS2fw GUwGwFkP5J4cqf+MzYhpOkXDprOLLBwAY6MJpi8dzZWFZ1pVt76yy/FPKVLhBFQ0vTTb UujK7twmAR2hEumJc8bcxEUeI7MT9qBGBBb44O+EScXOC/TYlwC08Zwxe1UU49WRjWmz QR+IjEEYWiUYojgMCWAw0YAozqqmhfkPInbnq0ro3oG6mFnPJyofVjB0t260u1fWsHSl Qiwt1a4t58dGNMZsEiHySER5O84gIxGFL3o1vlmFPsCqcDXWfr1A3vIaGXNo3QfPRGu6 MGWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=+wjEKjuSjyyTvniJ7+xgKOkW9e9BIcHlbOCG8zFLtfA=; b=HYUCglfVZarat/UsaCGxqt2MOzxeqlj8E1XWRPa2OVlTMLatwPUEiwM//3bXy1gd0X oIOUOxQoxLrCh+mxityCM1QTHcuW9zwfnHvX8m4sfSrTEj8l0f5jnRrfhzbsqpiHESNy 9DbkKnylQ5nErJpokRsHMBJKNXTE2SFr5fHbtevIK4sq6K3LObPP7OH2euVCMCpMFXZp t0CpJp9OicmwYSbT8cK05j3jAQ1hKYUWRnIKiSm7vBGiqgqHfOjJLcecyOIw0WClQ816 1H8wcSP4G9Z7HQwZQq8k213uPk4FFWWGlh4EFwh0uUj/lbg2cwiKDYhZudyi1g8fez3y ye2w== X-Gm-Message-State: AE9vXwPN18r/z4IQivzvr4lJR00LaSDW5OLkFsEWHqh44Wgc6CaJS8ewCvaiXmuKQt9+lA== X-Received: by 10.46.71.84 with SMTP id u81mr8259491lja.19.1473792977735; Tue, 13 Sep 2016 11:56:17 -0700 (PDT) Received: from chichi (ppp83-237-167-213.pppoe.mtu-net.ru. [83.237.167.213]) by smtp.gmail.com with ESMTPSA id s3sm4171824lja.49.2016.09.13.11.56.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 13 Sep 2016 11:56:16 -0700 (PDT) Message-ID: <841E948BC5B542BEBB0D53E5A2D064FA@chichi> From: "Valery Smyslov" To: "Paul Wouters" References: <08AB2EF60E5C4A9C8950483676619B4C@buildpc> In-Reply-To: Date: Tue, 13 Sep 2016 21:56:12 +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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-rfc4307bis-11 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 18:56:23 -0000 Hi Paul, > We have kept key lengths out of the tables on purpose. It matches the > tables at IANA that also do not list separate items for different key > lengths. Would "This requirement" instead of "This requirement level" > make that more clear? If you don't want to add key length column to the table, (what I think is a preferred way) then I suggest to add some words to corresponding paras that will reiterate: "these requirements are for those key sizes". >> And the comment (IoT) brings even more confusion. It states that >> "only 128-bit keys are at MUST level", while the line it refers to >> (ENCR_AES_CCM_8) indicates SHOULD level. > > That is an error. It should read "only 128-bit keys are at the SHOULD level" OK. And again I think it should be reiterated in the text below the table (besides the comment). > Note that I was hoping the (1) and (IoT) comments would appear similarly > indented so it becomes a little more clear and was planning to ask the > RFC Editor to ensure that. I was thinking of complaining about their current appearance (idented would be definitely better), but then I decided that it is a feature of xml2rfc. But you are right that RFC Editor can make them more better-looking. >> ENCR_AES_CBC is raised from SHOULD+ in [RFC4307] to MUST. It is the >> only shared mandatory-to-implement algorithm with RFC4307 and as a >> result it is necessary for interoperability with IKEv2 implementation >> compatible with RFC4307. >> >> However, it is not exactly true. The comment (1) indicates that both >> AES-128-CBC and AEC-256-CBC are now MUST, while in RFC4307 AES-256-CBC wasn't >> mentioned at all, so it definitely wasn't SHOULD+. >> So, this statement is true for AES-128-CBC and not true for AES-256-CBC. > > It is only because you do not want to see ENCR_AES_CBC without a key > size. We are talking about updating IANA entries, and the IANA entries > are not separate for keysize. We are talking about updating RFC4307 and it does include key size for AES-CBC (Section 3.1.1): For confidentiality, implementations MUST- implement 3DES-CBC and SHOULD+ implement AES-128-CBC. For integrity, HMAC-SHA1 MUST be implemented. Note, that it explicitely references AES-CBC with 128 bit key length, not any other. >> Section 3.2 >> >> If an algorithm is selected as the integrity algorithm, it SHOULD >> also be used as the PRF. >> >> That requirement isn't clear for me. Where it comes from? >> How it is justified? Is the document in the position to make such restrictive >> requirement? Isn't it a local policy matter? > > It came from me, after having talked to Tero about a TAHI test suite > test case. From what I understand from Tero, historically it was not > mandated in the IKEv2 RFC to use the same algorithm, although there is > really no argument in favour of using two different algorithms. If the > algo is good enough for INTEG, it is good enough for PRF. If one algo > is not good enough for either INTEG or PRF, then it is also not good > enough for the other. > > Our implementation does not allow one to specify a PRF different from > INTEG (unless INTEG is AUTH_NONE with an AEAD ENCR) > > I believe we ended up on SHOULD instead of MUST so this could be seen > as advise, and not a hard requirement. So it does not update the IKEv2 > core RFC in that respect. > > Do you have any use case where it makes sense that PRF != INTEG ? Sure. First, not any good MAC is a good PRF (but vice versa is true). Secondly, besides cryptographic properties there are also other considerations, like performance. For example, in Russia there is a standard MAC that is based on GOST cipher with reduced number of rounds. It is very fast, but it cannot be used as PRF. Coming back from Russian quirks, I can imagine the situation when I want to use SHA2-512 for PRF (because I don't want my conversation to be hacked offline in the future), but SHA1-HMAC-96 for MAC (because ICV tags are smaller comparing to SHA2 and I'm pretty confident in HMAC SHA1 security against _real_time_ attacks). And finally, I strongly oppose including such a restriction in this document, because from my point of view it is out of scope of the document. It has nothing with defining requirement levels for algorithms. Moreover SHOULD is a pretty strong requirement... >> PRF_HMAC_SHA1 has been downgraded from MUST in RFC4307 to MUST- as >> their is an industry-wide trend to deprecate its usage. >> >> I think some more reasons should be given besides "an industry-wide trend". >> Industry usually follows standards, so it's a bit silly to refer to industry >> trends >> as a reason here. I think some words about current concerns in the security >> of SHA1 should be added (like for PRF_HMAC_MD5 below). > > How about: > > "as cryptographic attacks against SHA1 are increasing, resulting in an > industry-wide trend to deprecate its usage" OK. >> Section 3.3 >> >> AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC4307 to MUST- >> as there is an industry-wide trend to deprecate its usage. >> >> See my comment above to the similar sentence in Section 3.2 > > Same. OK. >> It has been recommended by the CRFG and others as an >> alternative to AES-CBC and AES-GCM. >> >> What "others" mean? Isn't it too vague wording for Standards Track RFC? >> Either list these "others" (at least some of them) or remove reference to >> them. > > Agreed. I will propose removing "and others". OK. >> Section 3.2 >> >> PRF_HMAC_SHA2_256 was not mentioned in RFC4307, as no SHA2 based >> transforms were mentioned. >> >> This sentence makes little sence for me. Shouldn't second "mentioned" be >> "defined at that time"? > > They might have been defined, but what matters is that the document did > not reference them. Perhaps: > > As no SHA2 based transforms were referenced in RFC4307, PRF_HMAC_SHA2_256 > was not mentioned in RFC4307. Works for me. >> AUTH_AES-XCBC is only recommended in the scope of IoT, as Internet of >> Things deployments tend to prefer AES based pseudo-random functions >> in order to avoid implementing SHA2. >> >> s/AUTH_AES-XCBC/AUTH_AES-XCBC_96 (as in IANA Registry) > > Actually, we should add this to section 9 for renaming and call it > AUTH_AES_XCBC_96. Actually, it is already called AUTH_AES_XCBC_96 in the IANA registry. I wanted to point that it is erroneously called AUTH_AES-XCBC in this paragraph. >> Section 3.4 >> >> Group 19 or 256-bit random ECP group was not specified in RFC4307, as >> this group were not specified at that time. >> >> >> See my comment above about similar sentence in Section 3.2 > > The second "specified" here could be changed to "define" ? OK. > Paul Regards, Valery. From nobody Wed Sep 14 10:03:52 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF43712B35B for ; Wed, 14 Sep 2016 10:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTU-GoRHYO-E for ; Wed, 14 Sep 2016 10:03:46 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C38B12B33B for ; Wed, 14 Sep 2016 10:03:46 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id g192so31170321ywh.1 for ; Wed, 14 Sep 2016 10:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KUEjNnZ5xUoh9XIXrKgN1JdWj6ZcxcIRgffPrppYYgQ=; b=JOvuUm6kqlWJMb2VVAJsQ2uAIFi+3RiZObk0iGZ4hAhiHI6d2cGo7DLOx/x3jl79aL eSVDpdjDiZnsKHATy2igNGMaNs0s7Jwd5AxhstqOLkLiIOarB7GI41mYn4TKa4cNh9tS r8zp5MnolLLBo7iRWwX8g0NuyK+otTPZNkVj2Oe+dd4m2ku/nFCSfHiUGQYriFZ9gjxA zPV9bEWiyMxNDUAq4XRX2ZioMmm5p7PEXJrW3mrViY4DwV1WZuRUODsmpdbq81dbC0WY DhPmHSpHoZQDFoIK0RI2Wg6QpGCM2ngNgwBKpTXMfEIQYZs6Q82ahiTEc/as2B4x60ed srKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KUEjNnZ5xUoh9XIXrKgN1JdWj6ZcxcIRgffPrppYYgQ=; b=MMYIPSKUlc70leWN3iE9aX6mGjiSAoKV4NUn8tAUphDn1vpdb6bD8Sh6aaGG484J5c +qhjcYkXTqWi5lgzB7OkOy9IvI3Y+KeKiM8BbX396QpB8Ctr24tgdWDPknpWGVUM1/9F rIvy4Jwshe4Pasg5lBouLl6eJJSOnrst4GSGBT+1eb8tnHjz8WVyWGf/SPe30qQxoRuj xMdBB0GVZBG1oTrKm50JNMHD32/i98ZIU9A2KqI0QRngW8QGX7Gqc31dAExiHCcrYZYf 7bG3cPDtfFApY/h2C20vR41iecThFmHhCYc8xTfU0IbdgeAwVCUx05nD6J94mLC5pubJ EK7Q== X-Gm-Message-State: AE9vXwNhUEfPyQZvPKq9y1OHabyvJHKgs3SxGUFL8307YJuPbXH7HHavm8DzQsi/skcOSM/2a9YU/QDZMhCRCA== X-Received: by 10.13.254.135 with SMTP id o129mr4270759ywf.117.1473872625493; Wed, 14 Sep 2016 10:03:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.8 with HTTP; Wed, 14 Sep 2016 10:03:44 -0700 (PDT) In-Reply-To: <5C5029305BCB44E884B58F03462D5266@buildpc> References: <147367081810.14564.14875900515649411077.idtracker@ietfa.amsl.com> <5C5029305BCB44E884B58F03462D5266@buildpc> From: Kathleen Moriarty Date: Wed, 14 Sep 2016 13:03:44 -0400 Message-ID: To: Valery Smyslov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-09.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 17:03:51 -0000 Thank you! I will trigger the last call now and have this on the telechat in 2 weeks. Regards, Kathleen On Mon, Sep 12, 2016 at 7:25 AM, Valery Smyslov wrote: > Hi, > > a new version of the draft is published. > It includes text changes suggested by Kathleen. > > Regards, > Valery & Yoav. > > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IP Security Maintenance and Extensions of >> the IETF. >> >> Title : Protecting Internet Key Exchange Protocol version >> 2 (IKEv2) Implementations from Distributed Denial of Service Attacks >> Authors : Yoav Nir >> Valery Smyslov >> Filename : draft-ietf-ipsecme-ddos-protection-09.txt >> Pages : 29 >> Date : 2016-09-12 >> >> Abstract: >> This document recommends implementation and configuration best >> practices for Internet Key Exchange Protocol version 2 (IKEv2) >> 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: >> https://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-09 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ddos-protection-09 >> >> >> 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 > > -- Best regards, Kathleen From nobody Wed Sep 14 10:17:15 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9B912B369; Wed, 14 Sep 2016 10:17:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147387343439.1708.8788899054121573464.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2016 10:17:14 -0700 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org Subject: [IPsec] Spencer Dawkins' No Objection on charter-ietf-ipsecme-10-02: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 17:17:14 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-ipsecme-10-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Not for IPSECME, but for the IESG ... I don't object to this work: "There have been middle boxes blocking IKE negotiation over UDP. To make IKE work in these environments, IKE and ESP packets need to be transmitted over TCP. Therefore the group will define a mechanism to use IKE and IPsec over TCP. The group will also provide guidance on how to detect when IKE cannot be negotiated over UDP, and TCP should be used as a fallback" because what's described is going from UDP to TCP, which avoids a lot of challenges that going from TCP to UDP gives you, but it would be good for us to talk about all the ways that people are detecting poor performance, and even complete failures, in one protocol and switching to another protocol in response. I note that Ian Swett reported in Berlin that Google sees QUIC affected by UDP impairments, including blocking, about five percent of the time, and they also fall back to TCP, so this is a current problem affecting work in multiple areas. Perhaps this is a a good topic for an upcoming informal telechat. From nobody Wed Sep 14 12:08:19 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB7E12B463; Wed, 14 Sep 2016 12:08:18 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147388009800.19813.4336871193397025274.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2016 12:08:18 -0700 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, Kathleen.Moriarty.ietf@gmail.com, David Waltermire Subject: [IPsec] Last Call: (Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 19:08:18 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-09-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Sep 14 13:39:35 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A57B12B047; Wed, 14 Sep 2016 13:39:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147388557126.19774.12861528502883074078.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2016 13:39:31 -0700 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org Subject: [IPsec] Ben Campbell's No Objection on charter-ietf-ipsecme-10-02: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 20:39:31 -0000 Ben Campbell has entered the following ballot position for charter-ietf-ipsecme-10-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The milestones are all in the past. Should 2016 be 2017? Also, I notice the milestone list does not cover the full set of current goals--is that the intent? (I'm okay if it is; just checking.) From nobody Wed Sep 14 14:01:36 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2148012B054 for ; Wed, 14 Sep 2016 14:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5VXii3tJd8T for ; Wed, 14 Sep 2016 14:01:31 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0103.outbound.protection.outlook.com [23.103.200.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5495A12B004 for ; Wed, 14 Sep 2016 14:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zxQZM6PJCufEblfeC7sVBLJbsSushasQV3oJYdFtDNQ=; b=Awd//pRVREqKgHdXgWJ01K6qmG3uN+HZA5H17jkYeS7ZoYGmHSStG5IQu1ZFv9gi0+T25tlpvZrrEiOKOMrC7Y3D+8Puww55ksPB1LNa88BFrVo+i7FCl9yu+PAizps9ZZVXJ7JNR1UHqKiTM0P0FzPdi2WTaNl8q3Z7Q+SWOq4= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.10; Wed, 14 Sep 2016 21:01:29 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0619.011; Wed, 14 Sep 2016 21:01:29 +0000 From: "Waltermire, David A. (Fed)" To: Kathleen Moriarty , Valery Smyslov Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-09.txt Thread-Index: AQHSDNQdae9Gat/rGUaDDGgTimRboqB1tz5XgAODAACAAEIh8A== Date: Wed, 14 Sep 2016 21:01:29 +0000 Message-ID: References: <147367081810.14564.14875900515649411077.idtracker@ietfa.amsl.com> <5C5029305BCB44E884B58F03462D5266@buildpc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: d6b94806-4f01-43bd-f423-08d3dce24cdf x-microsoft-exchange-diagnostics: 1; MWHPR09MB1440; 6:Iza6pZnREwlbrckTCjhDmpMM5OAEMKYfTRIfC85FyIVpVuF1T6cXlIfJvoA28n1F2Ym5H17tVfC3PxKARSFTjaUw5MjABj0yQvjZDbWdaoiqI1B4x/Q2I0ltb8YRzp/J8hwG3B/cECVSawNF4K7KN4YJRqcdtoVsBhA4TIU8wOk0G/St4+2ZMUbUh9lG9VqmIMDumEZ/BrMaOU3L8Qr9WPZ+WsbW4Fo4Tst/nkKwM0MPLPk6K2n2t1lyoHwsA+IdowNWeDn5PTcebVw2/bNIdyYa/hejmZtMZy6kPV9IBGaLjhmOOp8c4tvWn2vLJeAgKsUeTzzFgvv5VeFL/ESFCg==; 5:AgXbkgMfzGFeyhF/q27CaPHfYA5kUOCcgwrmRNxAOLXdgfRjOdyb7O4KVmuRbBRhfSRo+zoKxYgrSRWS2O7LAVJSY9FBRzxEtoBKKJcpUUaadUK6FsjHAEPaB36B60FHsHYgDbBUSzxegZJmSPZ6qQ==; 24:OpFMlokPhEXo4K4eDAcc2dQqB325otwj8cEphiLl/VD6dN8RsVM9d6JNw65uMv5gmt1wui3QI8bYGA3YAhftUs8Fa7F7xyPcOV6e3GgklsQ=; 7:9EzCEBpSH3TPpe3tMAfg14qhodUsllChVOcQOg3W9lYF2V4iQr+aSXwNo6UKV5J9I+1YL0u4csD+qV6Wwx88nkA3ShcQGUiM6e8dysSEvxUSHGxPTMD6QvOl7GVZJ5wd8h2odAnH6/Q+iIL6DRQXMmMBSjbkueLSx6f9VoTCzroqjWskfRl02MA4xZgWk7L9x30Y/Uz/BH5ksoZsck3HV9SmrsmUHcdAoKjC8/sf5U7+d0fFQDTADIcVDl2xL8fQ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR09MB1440; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:MWHPR09MB1440; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1440; x-forefront-prvs: 006546F32A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(13464003)(24454002)(199003)(377424004)(4326007)(2900100001)(8676002)(7696004)(101416001)(11100500001)(54356999)(97736004)(106116001)(2950100001)(74316002)(50986999)(5660300001)(189998001)(5001770100001)(230783001)(99286002)(66066001)(76176999)(9686002)(5002640100001)(122556002)(105586002)(86362001)(3846002)(10400500002)(3280700002)(2906002)(6116002)(8936002)(87936001)(19580395003)(33656002)(7736002)(81166006)(92566002)(77096005)(15975445007)(102836003)(76576001)(68736007)(106356001)(19580405001)(3660700001)(305945005)(81156014)(586003)(7846002)(48284002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1440; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2016 21:01:29.7144 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1440 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-09.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 21:01:34 -0000 Kathleen and Valery, Thank you to both of you for your help on this. Regards, Dave > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Kathleen Moriart= y > Sent: Wednesday, September 14, 2016 1:04 PM > To: Valery Smyslov > Cc: ipsec@ietf.org > Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-09.tx= t >=20 > Thank you! I will trigger the last call now and have this on the telecha= t in 2 > weeks. >=20 > Regards, > Kathleen >=20 > On Mon, Sep 12, 2016 at 7:25 AM, Valery Smyslov > wrote: > > Hi, > > > > a new version of the draft is published. > > It includes text changes suggested by Kathleen. > > > > Regards, > > Valery & Yoav. > > > > > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> This draft is a work item of the IP Security Maintenance and > >> Extensions of the IETF. > >> > >> Title : Protecting Internet Key Exchange Protocol ver= sion > >> 2 (IKEv2) Implementations from Distributed Denial of Service Attacks > >> Authors : Yoav Nir > >> Valery Smyslov > >> Filename : draft-ietf-ipsecme-ddos-protection-09.txt > >> Pages : 29 > >> Date : 2016-09-12 > >> > >> Abstract: > >> This document recommends implementation and configuration best > >> practices for Internet Key Exchange Protocol version 2 (IKEv2) > >> Responders, to allow them to resist Denial of Service and Distribute= d > >> 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: > >> https://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-09 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ddos-protection= - > >> 09 > >> > >> > >> 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 > > > > >=20 >=20 >=20 > -- >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Sep 15 04:01:27 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA3712B113 for ; Thu, 15 Sep 2016 04:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhfSEOUSnAS9 for ; Thu, 15 Sep 2016 04:01:22 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF3412B0FD for ; Thu, 15 Sep 2016 04:01:21 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u8FB1EVg024457 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 15 Sep 2016 14:01:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u8FB1Ela001092; Thu, 15 Sep 2016 14:01:14 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22490.32633.818191.899460@fireball.acr.fi> Date: Thu, 15 Sep 2016 14:01:13 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <08AB2EF60E5C4A9C8950483676619B4C@buildpc> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 21 min X-Total-Time: 30 min Archived-At: Cc: IPsecME WG , Valery Smyslov Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-rfc4307bis-11 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 11:01:25 -0000 Paul Wouters writes: > > Section 4.2 > > > > | RSASSA-PSS with Empty Parameters | MUST NOT | | > > | RSASSA-PSS with Default Parameters | MUST NOT | | > > > > Well, I'm a confused with these requirements. As far as I > > understand the RSASSA-PSS parameters default to using a SHA1 for > > both hashAlgorithm and maskGenAlgorithm. Isn't more clear for > > readers to include > > > > | RSASSA-PSS with SHA1 | MUST NOT | | > > > > instead of these two lines, which in their current form don't > > explicitely refer to any cryptographic algorithm and force > > reader to dig into RSASSA-PSS specification to just get > > know that it was SHA1 meant? Or did I miss something? > > I'll leave this one to Tero. This is aligned with RFC7427, which has 3 examples for RSASSA-PSS. The first one is RSASSA-PSS with empty parameters. This means signature uses SHA-1 and it is MUST NOT. This is the one implementations generate if they use default parameters. The second one is an example with RSASSA-PSS with Default parameters explictly encoded. This is not according to the DER, but RFC4055 still requires that implementations need to understand it, even when generating they should be using the Empty Parameters version, and it still uses SHA1 so it is also MUST NOT. The 3rd example in RFC7427 is RSASSA-PSS with SHA-256, and that is specified as MUST. In the beginning of the 4.2 we already explictly specify levels for hash functions, i.e. SHA1 is MUST NOT. The next table only lists the version we have in the RFC7427 and which are not MAY. > > AUTH_AES-XCBC is only recommended in the scope of IoT, as Internet of > > Things deployments tend to prefer AES based pseudo-random functions > > in order to avoid implementing SHA2. > > > > s/AUTH_AES-XCBC/AUTH_AES-XCBC_96 (as in IANA Registry) > > Actually, we should add this to section 9 for renaming and call it > AUTH_AES_XCBC_96. It is already called that in the IANA registry. I fixed the "-" to "_" in the Berlin IETF, while talking to the IANA people for other things, and when noticed that typo in registry. So the IANA registry already says "AUTH_AES_XCBC_96" and that is what we should use also in this document, or we can also talk about AES-XCBC (without AUTH_ and _96), when we are talking about the algorithm in general (like AES-GCM vs AES-CBC). In this case, I think the AUTH_AES_XCBC_96 is correct one. -- kivinen@iki.fi From nobody Thu Sep 15 04:36:35 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5857412B1BD; Thu, 15 Sep 2016 04:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKip_9v0prLs; Thu, 15 Sep 2016 04:36:28 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05BBD12B184; Thu, 15 Sep 2016 04:36:27 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u8FBaOs8026018 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 15 Sep 2016 14:36:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u8FBaNWe004528; Thu, 15 Sep 2016 14:36:23 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22490.34743.18572.729248@fireball.acr.fi> Date: Thu, 15 Sep 2016 14:36:23 +0300 From: Tero Kivinen To: "Ben Campbell" In-Reply-To: <147388557126.19774.12861528502883074078.idtracker@ietfa.amsl.com> References: <147388557126.19774.12861528502883074078.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 17 min X-Total-Time: 18 min Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, The IESG Subject: [IPsec] Ben Campbell's No Objection on charter-ietf-ipsecme-10-02: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 11:36:29 -0000 Ben Campbell writes: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The milestones are all in the past. Should 2016 be 2017? Also, I notice > the milestone list does not cover the full set of current goals--is that > the intent? (I'm okay if it is; just checking.) I was assume that we need get the charter approved before we can add milestones for new items. I would expect the milestones to be something like this: Oct 2016 IETF Last Call on DDoS protection draft-ietf-ipsecme-ddos-protection Oct 2016 IETF Last Call on Curve25519 and Curve448 for IKEv2 draft-ietf-ipsecme-safecurves Nov 2016 IETF Last Call on cryptographic algorithms for IKEv2 draft-ietf-ipsecme-rfc4307bis Nov 2016 IETF Last Call on cryptographic algorithms for ESP / AH draft-mglt-ipsecme-rfc7321bis Dec 2016 IETF Last Call on TCP Encapsulation of IKE and IPsec draft-ietf-ipsecme-tcp-encaps Jan 2017 IETF Last Call on Using EdDSA in the IKEv2 draft-nir-ipsecme-eddsa Feb 2017 IETF Last Call on Split-DNS Configuration for IKEv2 draft-pauly-ipsecme-split-dns Feb 2017 IETF Last Call on Implicit IV in IPsec draft-mglt-ipsecme-implicit-iv Jun 2017 IETF Last Call on partially quantum resistant IKEv2 DDos and safecurves are already ready for IETF Last Call. rfc4307bis and rfc7321bis are in WG LC phase now, and should be ready soon. Tcp encaps, split dns and implict iv are waiting for more cycles in the WG, i.e. we want to push the current things out first and then concentrate on them. EdDSA is waiting for curdle to decide on the OIDs, and QR actually needs some work. -- kivinen@iki.fi From nobody Thu Sep 15 04:50:33 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A19E12B292 for ; Thu, 15 Sep 2016 04:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.79 X-Spam-Level: X-Spam-Status: No, score=-0.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, STOX_REPLY_TYPE=0.439] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hATTduWqMFDe for ; Thu, 15 Sep 2016 04:50:27 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0262F12B269 for ; Thu, 15 Sep 2016 04:50:27 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id g62so31260664lfe.3 for ; Thu, 15 Sep 2016 04:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=dnkms5h49GKobYRVQDTDugQDdjc/Uy+ilyG80HFzTRE=; b=NUoLorJdTzDfiOwJapSLrYKo2en9WHCxRbkGXjGT1oHvXPNbdehnvvgS5ZPZWcFqN5 G3Ktv8kmTfnkAIq7Lv53Cm91QExNWz1yv/dHbp/pfrPhZN2RQrIasnKQbw3lXgHmVHVF KT8RU6iWbEriiH/g0IUX2ejFEHW6KFuGIC5Ekz2Arb6N/Wqqlk8x4qQYrwfDp1ucs+df uSJNrHQ4V3wlG+6h8e1R/9CTqW5KyInC03IldYETfkBknvFaQKni1ja080t55O3vBdl1 pDQ0LKwbW4rCTxbJEhxFBVEc1P80ZXSXavX1lJ5Cuf7ftFelM567VGT/PMXCGl+OsmDp vdrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=dnkms5h49GKobYRVQDTDugQDdjc/Uy+ilyG80HFzTRE=; b=BJnikmt4YcTCELz0O0jNhXEO/2Gu+uWtXX9lk0E1UTcmXurGMombSDevP0gGacFOCJ IHG0dsTEDwGf19egd0F8h/gRUi0EZrwxbaPrUyaaMp7598kIm/JevZQnz90p80DIeghg SF85C8N7Xc/kONi5I+kAwpcNwY1eLmzYuB5g2FQ1WF9QRgJ+aK5hV90U9JC/o5akmT4n TcGOQ1HhBrHqYyWtH5y3Su84nW80X5dqrhWXgKbOHleSvBAPwGDhVnUAjjFs8YgW7Z3T dumzUHlon3Mn2/Ae/xG3Z94z8frdaGCZ8lnpdLTULHWnM5GkWySSCvgEqexe1eJh1vWT erlA== X-Gm-Message-State: AE9vXwNHHCEiVXYeaKQBv7tUMZvIammCqzpdgwlIu4vknOBxFKcU4ihEYUs4l0qQuzFtqg== X-Received: by 10.46.1.170 with SMTP id f42mr3481435lji.25.1473940224019; Thu, 15 Sep 2016 04:50:24 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id b71sm873559lfb.42.2016.09.15.04.50.22 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Thu, 15 Sep 2016 04:50:23 -0700 (PDT) Message-ID: <87306B3A1A824C1DA4CA23436223C2DF@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" , "Paul Wouters" References: <08AB2EF60E5C4A9C8950483676619B4C@buildpc> <22490.32633.818191.899460@fireball.acr.fi> Date: Thu, 15 Sep 2016 14:50:23 +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: Cc: IPsecME WG Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-rfc4307bis-11 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 11:50:31 -0000 Hi Tero, >> > | RSASSA-PSS with Empty Parameters | MUST NOT | | >> > | RSASSA-PSS with Default Parameters | MUST NOT | | >> > >> > Well, I'm a confused with these requirements. As far as I >> > understand the RSASSA-PSS parameters default to using a SHA1 for >> > both hashAlgorithm and maskGenAlgorithm. Isn't more clear for >> > readers to include >> > >> > | RSASSA-PSS with SHA1 | MUST NOT | | >> > >> > instead of these two lines, which in their current form don't >> > explicitely refer to any cryptographic algorithm and force >> > reader to dig into RSASSA-PSS specification to just get >> > know that it was SHA1 meant? Or did I miss something? >> >> I'll leave this one to Tero. > > This is aligned with RFC7427, which has 3 examples for RSASSA-PSS. Ah, I see your reason. However, I think that few extra words (probably in a comment) would make things more clear. Just clarify that both Empty and Default parameters mean using SHA1 which is MUST NOT. Note, that RFC7427 lists them only in Appendix, which is optional for reading and implementers might have been confused. Regards, Valery. From nobody Thu Sep 15 07:32:34 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A392F12B8CA; Thu, 15 Sep 2016 07:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k67Ft9LyYhaH; Thu, 15 Sep 2016 07:32:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26AC912B2FA; Thu, 15 Sep 2016 06:46:08 -0700 (PDT) Received: from [10.10.1.3] ([162.216.46.129]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u8FDk4ER001022 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 15 Sep 2016 08:46:06 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [162.216.46.129] claimed to be [10.10.1.3] From: "Ben Campbell" To: "Tero Kivinen" Date: Thu, 15 Sep 2016 09:46:04 -0400 Message-ID: <1151F821-EEA7-4F7A-942A-E22D3A9925BC@nostrum.com> In-Reply-To: <22490.34743.18572.729248@fireball.acr.fi> References: <147388557126.19774.12861528502883074078.idtracker@ietfa.amsl.com> <22490.34743.18572.729248@fireball.acr.fi> MIME-Version: 1.0 X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, The IESG Subject: Re: [IPsec] Ben Campbell's No Objection on charter-ietf-ipsecme-10-02: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 14:32:32 -0000 Thanks, Tero, that is helpful. Ben. On 15 Sep 2016, at 7:36, Tero Kivinen wrote: > Ben Campbell writes: >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> The milestones are all in the past. Should 2016 be 2017? Also, I notice >> the milestone list does not cover the full set of current goals--is that >> the intent? (I'm okay if it is; just checking.) > > I was assume that we need get the charter approved before we can add > milestones for new items. > > I would expect the milestones to be something like this: > > Oct 2016 IETF Last Call on DDoS protection > draft-ietf-ipsecme-ddos-protection > Oct 2016 IETF Last Call on Curve25519 and Curve448 for IKEv2 > draft-ietf-ipsecme-safecurves > Nov 2016 IETF Last Call on cryptographic algorithms for IKEv2 > draft-ietf-ipsecme-rfc4307bis > Nov 2016 IETF Last Call on cryptographic algorithms for ESP / AH > draft-mglt-ipsecme-rfc7321bis > Dec 2016 IETF Last Call on TCP Encapsulation of IKE and IPsec > draft-ietf-ipsecme-tcp-encaps > Jan 2017 IETF Last Call on Using EdDSA in the IKEv2 > draft-nir-ipsecme-eddsa > Feb 2017 IETF Last Call on Split-DNS Configuration for IKEv2 > draft-pauly-ipsecme-split-dns > Feb 2017 IETF Last Call on Implicit IV in IPsec > draft-mglt-ipsecme-implicit-iv > Jun 2017 IETF Last Call on partially quantum resistant IKEv2 > > DDos and safecurves are already ready for IETF Last Call. > > rfc4307bis and rfc7321bis are in WG LC phase now, and should be ready > soon. > > Tcp encaps, split dns and implict iv are waiting for more cycles in > the WG, i.e. we want to push the current things out first and then > concentrate on them. EdDSA is waiting for curdle to decide on the > OIDs, and QR actually needs some work. > -- > kivinen@iki.fi From nobody Thu Sep 15 08:27:45 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FF712B85D for ; Thu, 15 Sep 2016 08:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.266 X-Spam-Level: X-Spam-Status: No, score=0.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, STOX_REPLY_TYPE_WITHOUT_QUOTES=1.757] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4NDILQkaZea for ; Thu, 15 Sep 2016 08:27:39 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F1C12B661 for ; Thu, 15 Sep 2016 07:28:59 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id g62so37417918lfe.3 for ; Thu, 15 Sep 2016 07:28:59 -0700 (PDT) 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-transfer-encoding; bh=Q9Vu5PS6VaiI7065tk6RUCw62U+DEIgKQUK9Y3igcZo=; b=Xg9iRmU3zfgtK+s4LslVAFdLHmtJxwOHsn7l2FDb0UdYr6XrFvKwXjVfEaVeoL3j4h lQ6p7OdOAMKi7yzb2gGLt2fV/FitdXPgI+ZH3Jo8KHt1RBFzoH9WEjoPb/03Ep5MitvO a6k5VEagyrcB2KygkuK92M21P3P2E9xPpf2lsyJFLaHmL0ayQTz/5wBZi6vvvaS/5PDC 7Ji1b7bti4wN7Pvs8yImTeWWvnestbT0omlBCkaYyx5XVj+He4rczcsa1neyBLPH26Qx 4gBJS4NgDVrYq5qFvYPlRrwEsf13U0qUTkZ8yt84lBsEfPaRW0NlIUEVenxIP/Ftl01n aVnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version:content-transfer-encoding; bh=Q9Vu5PS6VaiI7065tk6RUCw62U+DEIgKQUK9Y3igcZo=; b=ONgd99is2XerLSQq/57MfsGdjC+KsV90KCjY5rydlSpVspMhAnkNrqwwZa+KvTjJZ2 QLsytFko64qBStdUCbI66W5yfWoOR46yoo35Ul89KnHf6XFCgekPlKC2ZOP5cHbbZQG8 Ca0q6wjyaT79WKbvn1uL2ThS4LUo6TzQ8J2Lw+dsXbnQ+atVRYLFB2dSqUj4iQM/DBvT HkBQNr9W2vK6TDC1e597amn/myoiqcxTSOK3BgF9XHnsF0LDy0VFBsUDvsiKXRrxlqRw HJQ8wKMNK3bTY0a/Gyk1809tl8Sp4cXMBBUNq7cSh7lsEu04ont9bho/Y1Orj4GssbYu XlAQ== X-Gm-Message-State: AE9vXwOE18pqPDSItVxVhNaETC9ZjkLmVUa0jXEfMMUYpBIc7zYQ3zAPGguozBa+Z4TLDg== X-Received: by 10.25.37.84 with SMTP id l81mr3818779lfl.41.1473949733751; Thu, 15 Sep 2016 07:28:53 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g38sm1063406ljg.24.2016.09.15.07.28.52 for (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Thu, 15 Sep 2016 07:28:53 -0700 (PDT) Message-ID: <4413733F9BF24D94821C1814E88C3C26@buildpc> From: "Valery Smyslov" To: "IPsecME WG" References: Date: Thu, 15 Sep 2016 17:28:53 +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: Subject: [IPsec] Interoperability problem concerning RFC 7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 15:27:44 -0000 Hi, we recently ran into one interoperability problem that is concerned with RFC 7427. We start testing RSASSA-PSS with another vendor product and found, that while it supports Digital Signature authentication method, it seems to not support RSASSA-PSS signatures in IKE. As a result, the SA is failed to be created if we use RSASSA-PSS (and we do use it because we want to be compliant with RFC-to-be draft-ietf-ipsecme-rfc4307bis, that states that with Digital Signature RSASSA-PSS-SHA256 is MUST). The problem is that RFC7427 doesn't provide any means to find out what kind of signatures peer supports. If you have RSA certificate, you need somehow to guess whether you can use newer PSS signature format or should stick to old PKCS 1 one. The SIGNATURE_HASH_ALGORITHMS notification doesn't provide any information of this kind. RFC7427 is silent whether support for RSASSA-PSS is required to be compliant with it, so I think it is absolutely legal now to have support for Digital Signature authentication method and have no support for RSASSA-PSS (as in the product we have tested with). The draft draft-ietf-ipsecme-rfc4307bis does requires that if Digital Signatures are supported, then RSASSA-PSS with SHA2-256 MUST be supported. However, even if it becomes RFC in near future, it'll take a couple of years before it is adopted by major vendors. I think that it is a more fundamental problem: RFC7427 allows peers to announce what hash functions they support, but the peers cannot announce what kinds of signatures (or what signature formats) they support. Few years ago life was simpler: there were a couple of widely used signature schemes and they use different types of public keys. So, if you had RSA certificate, you could be sure that RSA PKCS 1 signature format would be understood by anyone. Now we have new incompatible RSA signature format - RSASSA-PSS and mere having RSA certificate is not enough to choose right signature format. I envision that similar situation can repeat in the future with Elliptic Curve certificates. Now new kind of signature is being developed for Edwards curve public keys - EDDSA. However, as far as I anderstand, any Edwards curve key can be converted to short Weierstrass's form and used in ECDSA. So we'll probably have a mess when some implementations support EDDSA, while some use Edwards keys in ECDSA (at least for a while), that will result in interoperability problems. So, my question is - what to do with all this. 1. Do nothing. Coming back to the interoperability problem we have, it is possible to find some workarounds: - don't use RSASSA-PSS until it becomes ubiquitous (however if everybody follows this way it'll never become ubiquitous) - it is possible for the initiator to restart exchange if it receives AUTHENTICATION_FAILED while using RSASSA_PSS and use RSA PKCS 1 in the new run. However, this approach will slow down connection setup and waste resources of both initiator and responder. - it is possible for responder to look at the format of signature the initiator used and act in accordance - if the initiator doesn't use RSASSA-PSS then don't use it. These are all workarounds and they complicate implementations and waste resources for no good reason. 2. Add some indication of signature form/format the peers support. I can see two possible solutions. - define new entries in Hash Algorithms registry that are not hash functions but are rather signature formats. For example, add RSASSA_PSS. If it is included in SIGNATURE_HASH_ALGORITHMS notification. it will mean that this format is supported with any real hash algorithms that are included in this notification. It is clearly a hack of RFC 7427. - define new notification SIGNATURE_FORMATS, which will include supported signature forms/formats. It seems to be a most "proper" way, however it is the slowest one (new RFC is needed). What the WG thinks of all this? Regards, Valery. From nobody Thu Sep 15 09:21:35 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AEE12B599; Thu, 15 Sep 2016 09:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dE63DYhgsIpe; Thu, 15 Sep 2016 09:21:31 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AC9612B389; Thu, 15 Sep 2016 08:24:54 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id g192so60435254ywh.1; Thu, 15 Sep 2016 08:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8PBv/4bskaHRprJiYM+MfEAJ4mGeqHuxrYBLX1kIiCc=; b=of4FFOnGkujMb93CQWPN2gLW1G1XrSFTpIGyd7pBlSDKrAJpn2RRzJY9px7tBETS7g Bcg0g2gryqak4IjPpNlxsIagnB4a0KzMrxF2A2pYNOtzl/9eFJKvE6oS0EodLBsFIQds wDq7EzeQSHIyYAsEWcqicv60BQWYP13BWU029BWxtI0dJYxwH0TET4+0X+skYQAxwBAX dHwsPNhiKdUqK2dYQRIXQSnKKGpw4ybLtwi28lMMP61RwajU8FNKGowrVrKFlqPl2HOX PROT1LtlPFjTPPRVwZfAlB9fcr6oyC3gxJg5HFb5PIYgnj2+O/2llB0Iq6Scc7qTcVw6 DbtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8PBv/4bskaHRprJiYM+MfEAJ4mGeqHuxrYBLX1kIiCc=; b=KkiG0y1FiXUGEdu8nv58usVV2J526K2KJ8DvezZvT1WyCI2RXeT551l9W5SWwIDHV0 UH/nzPpQl9/ZAoIfMpcc+VpX5AjOeteeu8rzTNOIZMJplNDq3IefjSWAqfH9I8xC3IU6 J09ueLwKnxpPwFlq/T1BQGftgYw0LcLt8WeKBQoYlJyDWCn0UhtPecmus9NdLmAPFum8 IqtPjSQbhtgnn1nhpeE/+4klmox/mWRuspXlTH/awFrKlpYeb6L2C3bgPN3d8cDzqdl/ O07j+IY/sY6/z7A8FWM/dO0rq3oPbnQnR8e8+3xQtBjbKwYTtHWf5tx+jWfehwvgR8wD XlkQ== X-Gm-Message-State: AE9vXwPHZ2ik3s19GKh+GYL3LM1NGUkrG1vAHT4cvpmRSPkKEXovsTEgUgvz1P1V1/VEslj7bsonvCL6QndtMQ== X-Received: by 10.129.90.68 with SMTP id o65mr9757128ywb.142.1473953093365; Thu, 15 Sep 2016 08:24:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.8 with HTTP; Thu, 15 Sep 2016 08:24:52 -0700 (PDT) In-Reply-To: <1151F821-EEA7-4F7A-942A-E22D3A9925BC@nostrum.com> References: <147388557126.19774.12861528502883074078.idtracker@ietfa.amsl.com> <22490.34743.18572.729248@fireball.acr.fi> <1151F821-EEA7-4F7A-942A-E22D3A9925BC@nostrum.com> From: Kathleen Moriarty Date: Thu, 15 Sep 2016 11:24:52 -0400 Message-ID: To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ipsec@ietf.org" , "ipsecme-chairs@tools.ietf.org" , ipsecme-chairs@ietf.org, The IESG , Tero Kivinen Subject: Re: [IPsec] Ben Campbell's No Objection on charter-ietf-ipsecme-10-02: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 16:21:33 -0000 Tero, please do add them and I'll approve. We can do these separately, but having them up-to-date is helpful and it is also helpful to have them with a charter so the scope of work is clear. SOrry I didn't catch that. Thank you, Kathleen On Thu, Sep 15, 2016 at 9:46 AM, Ben Campbell wrote: > Thanks, Tero, that is helpful. > > Ben. > > On 15 Sep 2016, at 7:36, Tero Kivinen wrote: > >> Ben Campbell writes: >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> The milestones are all in the past. Should 2016 be 2017? Also, I notice >>> the milestone list does not cover the full set of current goals--is that >>> the intent? (I'm okay if it is; just checking.) >> >> I was assume that we need get the charter approved before we can add >> milestones for new items. >> >> I would expect the milestones to be something like this: >> >> Oct 2016 IETF Last Call on DDoS protection >> draft-ietf-ipsecme-ddos-protection >> Oct 2016 IETF Last Call on Curve25519 and Curve448 for IKEv2 >> draft-ietf-ipsecme-safecurves >> Nov 2016 IETF Last Call on cryptographic algorithms for IKEv2 >> draft-ietf-ipsecme-rfc4307bis >> Nov 2016 IETF Last Call on cryptographic algorithms for ESP / AH >> draft-mglt-ipsecme-rfc7321bis >> Dec 2016 IETF Last Call on TCP Encapsulation of IKE and IPsec >> draft-ietf-ipsecme-tcp-encaps >> Jan 2017 IETF Last Call on Using EdDSA in the IKEv2 >> draft-nir-ipsecme-eddsa >> Feb 2017 IETF Last Call on Split-DNS Configuration for IKEv2 >> draft-pauly-ipsecme-split-dns >> Feb 2017 IETF Last Call on Implicit IV in IPsec >> draft-mglt-ipsecme-implicit-iv >> Jun 2017 IETF Last Call on partially quantum resistant IKEv2 >> >> DDos and safecurves are already ready for IETF Last Call. >> >> rfc4307bis and rfc7321bis are in WG LC phase now, and should be ready >> soon. >> >> Tcp encaps, split dns and implict iv are waiting for more cycles in >> the WG, i.e. we want to push the current things out first and then >> concentrate on them. EdDSA is waiting for curdle to decide on the >> OIDs, and QR actually needs some work. >> -- >> kivinen@iki.fi > -- Best regards, Kathleen From nobody Thu Sep 15 10:30:25 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1677F12B164; Thu, 15 Sep 2016 10:30:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147396062104.21740.5732784526873432354.idtracker@ietfa.amsl.com> Date: Thu, 15 Sep 2016 10:30:21 -0700 Archived-At: Cc: ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-safecurves@ietf.org, Tero Kivinen Subject: [IPsec] Last Call: (Curve25519 and Curve448 for IKEv2 Key Agreement) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 17:30:21 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Curve25519 and Curve448 for IKEv2 Key Agreement' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-09-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange (IKEv2) protocol. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ballot/ No IPR declarations have been submitted directly on this I-D. Downward Normative References There is normative reference to the informational RFC 7748. The RFC 7748 is the actual algorithm description published by the CFRG. From nobody Fri Sep 16 06:05:57 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FB112B4AF for ; Fri, 16 Sep 2016 06:05:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147403115580.25330.4137698080539842002.idtracker@ietfa.amsl.com> Date: Fri, 16 Sep 2016 06:05:55 -0700 From: IETF Secretariat Archived-At: Subject: [IPsec] Milestones changed for ipsecme WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2016 13:05:55 -0000 Changed milestone "IETF Last Call on DDoS protection", set due date to October 2016 from March 2016. Changed milestone "IETF Last Call on Curve25519 and Curve448 for IKEv2", set due date to October 2016 from March 2016. Changed milestone "IETF Last Call on cryptographic algorithms for IKEv2", set due date to November 2016 from March 2016. URL: https://datatracker.ietf.org/wg/ipsecme/charter/ From nobody Fri Sep 16 06:14:21 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE4512B25E; Fri, 16 Sep 2016 06:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vj7JQDDiHrWQ; Fri, 16 Sep 2016 06:14:16 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C28612B176; Fri, 16 Sep 2016 06:06:22 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u8GD6GZd001594 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Sep 2016 16:06:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u8GD6FJ2001358; Fri, 16 Sep 2016 16:06:15 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22491.60999.763096.698460@fireball.acr.fi> Date: Fri, 16 Sep 2016 16:06:15 +0300 From: Tero Kivinen To: Kathleen Moriarty In-Reply-To: References: <147388557126.19774.12861528502883074078.idtracker@ietfa.amsl.com> <22490.34743.18572.729248@fireball.acr.fi> <1151F821-EEA7-4F7A-942A-E22D3A9925BC@nostrum.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Cc: "ipsec@ietf.org" , Ben Campbell , ipsecme-chairs@ietf.org, The IESG , "ipsecme-chairs@tools.ietf.org" Subject: Re: [IPsec] Ben Campbell's No Objection on charter-ietf-ipsecme-10-02: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2016 13:14:20 -0000 Kathleen Moriarty writes: > Tero, please do add them and I'll approve. We can do these > separately, but having them up-to-date is helpful and it is also > helpful to have them with a charter so the scope of work is clear. > SOrry I didn't catch that. Added now. -- kivinen@iki.fi From nobody Fri Sep 16 09:18:02 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE3612B2E1 for ; Fri, 16 Sep 2016 09:18:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147404268036.25297.11249682518089501920.idtracker@ietfa.amsl.com> Date: Fri, 16 Sep 2016 09:18:00 -0700 From: IETF Secretariat Archived-At: Subject: [IPsec] Milestones changed for ipsecme WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2016 16:18:00 -0000 Changed milestone "IETF Last Call on cryptographic algorithms for ESP / AH", set state to active from review, accepting new milestone. Changed milestone "IETF Last Call on TCP Encapsulation of IKE and IPsec", set state to active from review, accepting new milestone. Changed milestone "IETF Last Call on Using EdDSA in the IKEv2", set state to active from review, accepting new milestone. Changed milestone "IETF Last Call on Split-DNS Configuration for IKEv2", set state to active from review, accepting new milestone. Changed milestone "IETF Last Call on Implicit IV in IPsec", set state to active from review, accepting new milestone. Changed milestone "IETF Last Call on partially quantum resistant IKEv2", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/ipsecme/charter/ From nobody Fri Sep 16 10:11:26 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EACB912B068; Fri, 16 Sep 2016 10:11:24 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147404588495.25329.12740141762976356234.idtracker@ietfa.amsl.com> Date: Fri, 16 Sep 2016 10:11:24 -0700 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, The IESG Subject: [IPsec] WG Action: Rechartered IP Security Maintenance and Extensions (ipsecme) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2016 17:11:25 -0000 The IP Security Maintenance and Extensions (ipsecme) WG in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. IP Security Maintenance and Extensions (ipsecme) ----------------------------------------------------------------------- Current status: Active WG Chairs: David Waltermire Tero Kivinen Assigned Area Director: Kathleen Moriarty Security Area Directors: Stephen Farrell Kathleen Moriarty Mailing list: Address: ipsec@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: https://mailarchive.ietf.org/arch/browse/ipsec/ Charter: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: IKEv2 contains the cookie mechanism to protect against denial of service attacks. However this mechanism cannot protect an IKE end-point (typically, a large gateway) from "distributed denial of service", a coordinated attack by a large number of "bots". The working group will analyze the problem and propose a solution, by offering best practices and potentially by extending the protocol. IKEv2 utilizes a number of cryptographic algorithms in order to provide security services. To support interoperability a number of mandatory-to-implement (MTI) algorithms are defined in RFC4307 for IKEv2 and in RFC7321 for ESP/AH. There is interest in updating the MTIs in RFC4307 and RFC7321 based on new algorithms, changes to the understood security strength of existing algorithms, and the degree of adoption of previously introduced algorithms. The group will revise RFC4307 and RFC7321 proposing updates to the MTI algorithms used by IKEv2 and IPsec to address these changes. There is interest in supporting Curve25519 and Curve448 for ephemeral key exchange and EdDSA for authentication in the IKEv2 protocol. The group will extend the IKEv2 protocol to support key agreement using these curves and their related functions. IKEv1 using shared secret authentication was partially resistant to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify IKEv2 to have similar quantum resistant properties than IKEv1 had. There have been middle boxes blocking IKE negotiation over UDP. To make IKE work in these environments, IKE and ESP packets need to be transmitted over TCP. Therefore the group will define a mechanism to use IKE and IPsec over TCP. The group will also provide guidance on how to detect when IKE cannot be negotiated over UDP, and TCP should be used as a fallback Split-DNS is a common configuration for VPN deployments, in which only one or a few private DNS domains are accessible and resolvable via the tunnel. Adding new configuration attributes to IKEv2 for configuring Split-DNS would allow more deployments to adopt IKEv2. This configuration should also allow verification of the domains using DNSSEC. Working group will specify needed configuration attributes for IKEv2. Currently, widely used counter mode based ciphers send both the ESP sequence number and IV in form of counter, as they are very commonly the same. There has been interest to work on a document that will compress the packet and derive IV from the sequence number instead of sending it in separate field. The working group will specify how this compression can be negotiated in the IKEv2, and specify how the encryption algorithm and ESP format is used in this case. This charter will expire in December 2017. If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Milestones: Oct 2016 - IETF Last Call on DDoS protection Oct 2016 - IETF Last Call on Curve25519 and Curve448 for IKEv2 Nov 2016 - IETF Last Call on cryptographic algorithms for IKEv2 Nov 2016 - IETF Last Call on cryptographic algorithms for ESP / AH Dec 2016 - IETF Last Call on TCP Encapsulation of IKE and IPsec Jan 2017 - IETF Last Call on Using EdDSA in the IKEv2 Feb 2017 - IETF Last Call on Split-DNS Configuration for IKEv2 Feb 2017 - IETF Last Call on Implicit IV in IPsec Jun 2017 - IETF Last Call on partially quantum resistant IKEv2 From nobody Wed Sep 21 11:33:20 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8FA12B62F for ; Wed, 21 Sep 2016 11:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsWlCRVewm9c for ; Wed, 21 Sep 2016 11:33:15 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0099.outbound.protection.outlook.com [104.47.1.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F58712B8FC for ; Wed, 21 Sep 2016 11:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tXmKtvqLLDJ2HCjdp3K8Pzvup/ib2vnuEKJiIqdnTbI=; b=YD+J3MH9vF70ykxVkmeTBWgIA1C1C2LP7UfMBmfggqSr+0DUmu3jWpR8djLD1WMcjVwPSCSZAoNGaJ0JJysLgbjuBvQsfX+toPyj2sD2QUcSN98ZLkZn87mr2iErp5caBcufHuU/pm7+vTBWMSsHjj/McQ7NyIPtC9CuM1qpLh4= Received: from AMSPR04CA0051.eurprd04.prod.outlook.com (10.242.87.169) by VI1PR04MB1119.eurprd04.prod.outlook.com (10.161.110.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.2; Wed, 21 Sep 2016 18:33:11 +0000 Received: from DB3FFO11FD043.protection.gbl (2a01:111:f400:7e04::101) by AMSPR04CA0051.outlook.office365.com (2a01:111:e400:8014::41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.2 via Frontend Transport; Wed, 21 Sep 2016 18:33:12 +0000 Authentication-Results: spf=none (sender IP is 40.103.22.100) smtp.mailfrom=philips.com; cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (40.103.22.100) by DB3FFO11FD043.mail.protection.outlook.com (10.47.217.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5 via Frontend Transport; Wed, 21 Sep 2016 18:33:11 +0000 Received: from HE1PR9003MB0235.MGDPHG.emi.philips.com (129.75.99.148) by HE1PR9003MB0234.MGDPHG.emi.philips.com (129.75.99.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.8; Wed, 21 Sep 2016 18:33:10 +0000 Received: from HE1PR9003MB0234.MGDPHG.emi.philips.com (129.75.99.147) by HE1PR9003MB0235.MGDPHG.emi.philips.com (129.75.99.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.8; Wed, 21 Sep 2016 18:33:09 +0000 Received: from HE1PR9003MB0234.MGDPHG.emi.philips.com ([129.75.99.147]) by HE1PR9003MB0234.MGDPHG.emi.philips.com ([129.75.99.147]) with mapi id 15.01.0629.015; Wed, 21 Sep 2016 18:33:09 +0000 From: "Garcia Morchon O, Oscar" To: "Scott Fluhrer (sfluhrer)" , "IPsecme WG (ipsec@ietf.org)" Thread-Topic: Quantum Resistance Requirements Thread-Index: AdH0G8ijQKeg6MaXRiG9vXmtSf0/rwUZFu7AAu0Q5gA= Date: Wed, 21 Sep 2016 18:33:09 +0000 Message-ID: <310149fca5cb4474b31d065becfffde2@HE1PR9003MB0234.MGDPHG.emi.philips.com> References: <29427d45853b4e01b6e38674f8570721@XCH-RTP-006.cisco.com> In-Reply-To: <29427d45853b4e01b6e38674f8570721@XCH-RTP-006.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [38.64.180.98] X-MS-Office365-Filtering-Correlation-Id: bde48b4b-f511-468b-bb94-08d3e24dbde0 Content-Type: multipart/alternative; boundary="_000_310149fca5cb4474b31d065becfffde2HE1PR9003MB0234MGDPHGem_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: HE1PR9003MB0235.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:40.103.22.100; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(7916002)(2980300002)(428002)(377454003)(199003)(374574003)(189002)(71364002)(55904004)(85714005)(57704003)(512954002)(5001770100001)(7696004)(7846002)(101416001)(586003)(69596002)(54356999)(76176999)(260700001)(97736004)(16236675004)(68736007)(7116003)(356003)(2906002)(107886002)(8936002)(10400500002)(33646002)(50986999)(19300405004)(7736002)(108616004)(3900700001)(2900100001)(84326002)(8676002)(11100500001)(5660300001)(189998001)(86362001)(2950100001)(9326002)(66066001)(87936001)(15975445007)(6116002)(19625215002)(106466001)(81156014)(81166006)(19580405001)(24736003)(790700001)(626004)(105586002)(3846002)(102836003)(92566002)(19580395003)(3480700004); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR04MB1119; H:011-smtp-out.Philips.com; FPR:; SPF:None; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD043; 1:HuLMq+9e440WbT3P5K19rPIf0PAAWK8c2Hdwep8bzHAnRwBVf27LTNONg/L49OA1qSihbMJzjA21kXcHg3tMIcbOBjKVd6gZgv4XNkWDMfzUAyzD6rbGuWDduxmHx7ELCcbaHOTXYl0qVLrYCJ1wnjFQ9y9U8VwCUzYoXLQhNnLsu2XkllEH4PTOOBOC1bjQbDLrIKEO2OuQdLqA9UZGI5ktbzqNgr0t+Ok3LqxstK6dTKdkkdIMzbfI6X+dEH4N541v8tcJlvqun+7TG1aBchUkREt+agKI5fHvY97qe2AeDp81bu7DuHi+mtWifNY51IdKn8ctvJv1BRHZ4Gglxw/ILMJH6qLacBXt6Df6HZdn/ItexnYbHiBCkC5UPwOpiNnuXW9kpVdk9ujMVqJ93FErAuULbDBf1vxv53Vs6shDxFYVT8xm15hJHvWLN3O/CqD5FVJEbGuXmi4DwAYPq9QcqXwOQo7QuiJXeKwdxRCZyxi09hcfbl8pnTYVrCQo X-CrossPremisesHeadersFiltered: DB3FFO11FD043.protection.gbl X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1119; 2:ixU3v1HR21YzJEkKdz+gGQ83eCD4hXhnZn5gqw9MHwu8oad+PsN4579FPVx5Ll09JIkSukGBykA4sv1aIjM8x80oyNYtEol1xu7Pvfr9Wni/sXgLJ6bUxgWvdxCRA3b/4vfJ/HAB+ZO4QLWsnQD0Y9S4RZloRMQz89Ojx0pbqxKZiyGqhXBq9OppnA5DEf5Y; 3:fi2ilDckfuU0gp6U43GttdxxEyzvhyZiStbNrnp56spYbMixpWMDgIt5KfNDiYAj83hbrzqnNZz4wgs/vQKLr9P5Saa2D+wN7vhdHTziZn7Bbewxe3Mfsb3cDpNoTzQ15zywX8NXxgV3n7Ky9Zl1m9PrZD9aFp+rE0BBQ8V6Z5W0p0wg3A3qofCY2MCJmeY1VnRf6NK8DI4xghvdW7hBLExYIv1ziBazuP/9pK9d4cA= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR04MB1119; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1PR04MB1119; 25:y8PhfMgpsmLbnA5d1Kc0slgGXG4KaNvS8Siy3HaoF?= =?us-ascii?Q?AtzAzPhCTHLpKTckFYcs2CJVLh0nVleL9OW68EqaGog/FmqFDlydRyXcLUAF?= =?us-ascii?Q?XT3cHEonv+C3unIOYIeKLaYXym+BD0K3A1dFZ04C3ogHTzesrkGE/4ZefINr?= =?us-ascii?Q?vMRdx4rJ0j5p+lDP8fk7KngYj07qqi3O3a4kfz2OfVxR7WO5AqAMWJ7f8h0D?= =?us-ascii?Q?KMit7/dyFogGBUBHHMP4wwzY0fOdBTTtPS4n6uC2slncQeTer0u0MVf1gW8z?= =?us-ascii?Q?7ctVBTyNrgkDXlUgpu6Z0Zx/lGjGrFZ7DbcX5BdU/1iP8Y+/CdZVEnN/bDPa?= =?us-ascii?Q?yBI2o/CQe31TjtDzRrRZECztv34+lCXz5iIxqxKOK0kIx6HWqwRoMD3Y4uex?= =?us-ascii?Q?EghneK8gS+yVkOzERowXuMxJSo9j+Cps5Alb0h+pIMDeQyHqS11cL2QKk2lR?= =?us-ascii?Q?pK8XDa/332XKKhvGQR3u8GdtxyW3l3q0Z5YOIN8tNNq/TLkc8FsYUE+4E6mb?= =?us-ascii?Q?mN/Uz/OuBebAeP+r1WAfG8S48PQ03FakdlzucwLuaBCOwJLEuFNnw0G+s1CS?= =?us-ascii?Q?+vxgpzpTN5Q4or7Tom7GTNXa9pyGz75ukKAj24sHqexvE8DIf05x5+u2pHgw?= =?us-ascii?Q?AvUCp3Og+Ie2WDow1wFF8PoC4hBIs18GuDrDfFgUWR9mK8zwn1vD2wv1Tj7w?= =?us-ascii?Q?V8HkhxHrMYkt6nFaoWQoEOsEa6NNq/JRFiPPlqPDYBIpU49FXljFYHN7d+aO?= =?us-ascii?Q?hLCOFPXlA/gvV34BKzVMHOERsrMcFvUAS0hiJ3udg/FnnJ6cKfAsXVzNZ9m0?= =?us-ascii?Q?JN+DtaCrqLBzd5YqK9Do7OGfrzcVSCnOIdmEDSeb1ZDKM2k2gRYr4EpkMXux?= =?us-ascii?Q?v9ynXfymRdJ1s9vHjxGOuyyv5qoOVOifVFRglKE1IJ3KZO+/HBEMtwSf46KC?= =?us-ascii?Q?egTdFynTOyTh1fs0TnA/iiCbG//LH/qyulR3jpQJTknL6CygYndvXarUQqoR?= =?us-ascii?Q?jk=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1119; 31:5FjNyqwtlMgJu9KCRUXEQrnkK4yAnN4yeHBTJxNJTS1tokqm9deUvNal4jJ8jEK58KzAG3IaArQsoomo/nT/PemjEfjZXS3S3fhDKNgSyhxJsSEZ4aI1XOLlI5rJaSQN8Xs6LJfK7S5wmOzaAvrR2MyQtDmRMKYep0FQJBTM+XLYSmbeewbfGga676KPIHPF1Ba3GWfThUFBTmsWu2vM7aWsPV6Kqw27dT9eljoTPIQ=; 20:2r5K2B1udvwQ0adHs1dbMZsm8MYT1VSizplTczLeZTWm6UQPt/OyHq8D6tGbJXOcX5Jkf0CjShZZJRU9qHJV+EIV2q6tPr65ur5KVFSlttySQekm7i2NBWmWI1V4U/YiESEaSxDchJ7ZsdDIeDM3eSX9Z8gl8Rh2yy1qfTeSc6oXmSbVZO7+Xwf0VAey9unzE1Q4aEnuBTmXysnSqrKTkEIwO43jSiycskT1RLwB6p5pTmZdobV8Fy8DgDMZ7Y1wih9YFTE6kuGJKJ9YJ7UrfrpeQNtITn5/LasB4LwaDtusK7xpHM0bu4Adtm/gT5yMerdqTkkaWPod0rRw7UFtk9ta3XTe/4t0EWPbUMB9y6fhBqpcWRZfXdzHVaxP6WXKJyHbgZLWRqK5NbVYXTRUBWZj4w1Do17m0eBP3UWn1scQIXBLJQse9NzdXFFNm9KAIJUqx+ZzcDbGofW/Q+5XjgPQfloZJCnrER1W3RK3IEhN4Kr1P546AEMjAACz22VL X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(13016025)(13018025)(10201501046)(3002001)(6055026); SRVR:VI1PR04MB1119; BCL:0; PCL:0; RULEID:; SRVR:VI1PR04MB1119; X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1119; 4:ecalGuz2Z451THaIZr5tW+GYFDV4qbzYCiHWbZ7aJsZAIzefOMLWO9XjRLYTUwkVsB9u1NGflx5sYLAJ7oqIuKwZIHYNYNxUbQ4ib/ySIEf7wC+R98LI/JO/vEbdU30X88qbNfZrXWuLx5R36CXu5Z8+/PiZk/a8uJwfJleYlzInZ5y2XCB4Xohx3QdO7SSljE9a3t6GaIRRjizak9cXiL6ETTvhcJOx8NilzhrSnwFOJSKe/a0/eYt3SOgHYVZKKcGUZE9ISHP5xueihqQIAJZU5U87A40RvrCRrDo5nar6t7Nexjc29aIDf5QiiGmymKrNiFlBYT+LhnO3tQ2eRw7yhVzik+62SOi6fEEEYVskgeTXd+i0E/PK2koovDX8JyN6lbgz3nVHTfHlfYYpd+SRGsmMFpqnokcWbw3OVqR2K4lwIbiapHzUjPRt8vzihispYGo1nwYuEA134jIlr7gr+1ZquacmRNB/1bPJr2MZhNQ3IDJj70d9+8BWFYS4Oug1Hamu8tPP0Pcs0/k7lg== X-Forefront-PRVS: 007271867D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1PR04MB1119; 23:KD0H2e3uo1z/k1Zphi9As7OH/404Zkq9bJIGQw/7h?= =?us-ascii?Q?o9PRrF2L1KRrx0CkFl2WAVps5gglW2gAOY6deSUS1pLuF2/zsCra11lA/abz?= =?us-ascii?Q?I7xyCa4ewhQ1eQIBk1prMCD7GqjdcuTuFn0fqlX9KaZFnIxsK683GrSid/te?= =?us-ascii?Q?9Vc7p9Jiu9XME+Fh4Wc2q1sqjE0N2nufacgD3JdqEI8NMUtJyTRxemTdglY4?= =?us-ascii?Q?UrIDuLHHWTuKSTO7cdsMVsrY4ACGvTozmRjlGflHLyYXgylAKO4+C3DGPVV4?= =?us-ascii?Q?8OPILW1nnNsJ96s1wI5Ev/PVJebd8Du66eclak4MlF8SwS548/HNXO7IXHP8?= =?us-ascii?Q?GXtNAvDYyj3bkYdhItimjUv0uDaNtVFfEnuHpZ+pAsFAepiDe80D9qaw7Fjt?= =?us-ascii?Q?75gnr3X3qmhZ7Q5lCNl+8mngroDDpW6XmY1T0mieI53ZhfOYwhxgKkWV7ZzV?= =?us-ascii?Q?AiP1g+P7WBBvp5rMk5WdOqJyVyXAgEGJc3d60wCVSFDlvnmi67SFD9BePWma?= =?us-ascii?Q?3yL7MpiDmxpoU4Iz4Wg1MnsByr9RAJTeAdR3YcKd2/XQnHoLK70uPv4wShgx?= =?us-ascii?Q?HLW9UJicJp/LOVIUl1F6JhshjEBoVzWJzqy1u4R6EjDk2gUBbT2Qj/eihTzw?= =?us-ascii?Q?a/YbVEtUTOvv3YgelfCkJtTXtw4wnEI66UpGvtQ2jEKzWrVNUhrLIZ1HSRPP?= =?us-ascii?Q?/IrZlKyUfZuOSzw4bi7qMF3RNMocy5l2btsMcEHVELBe2MJkNgnLXJ+kvyac?= =?us-ascii?Q?/TWzMe0c2aMdkCxo1PjwRyQGi2pLS8zK9Gp0uqOhWLjlh6McKSXaxp4tueRC?= =?us-ascii?Q?wPBFWu95RUtSSrba10Bv9bksn6VQ0/T0E5e4OHNGEdsAaZhKO43rme7EKJXR?= =?us-ascii?Q?iNEe9DKglBnrapIxSWTO3AqgBxXtymfM2ABXYTCX6XADmEX5yZVwoD57iioi?= =?us-ascii?Q?JsP0vQ+egZOvilESabzZUGf15miGPhWGBnB4DmimXCZJdea3/Y+xrriQUAKD?= =?us-ascii?Q?kmwjXCIaAgWGiDYCwBMYdnamIEojuh9gtdul7IcSVbj4GLQQVoIUypZ9vigx?= =?us-ascii?Q?ZEFSspQEGMq+om76z97KG/NYJmk9iy6QeYxlDgidLcScNPd4jRBWNOdsY6yY?= =?us-ascii?Q?gbjlV3Ns/HsOX8AuErzSK3qz5LfYSJSFOtlMv8hzJEnp0nO5m3her9bci6sP?= =?us-ascii?Q?ShLSHegBtFqueAJ+TRJxh6h2xNcWmif82Pwn/zfBwSaOwLVDR+aiU7Ml2vT0?= =?us-ascii?Q?eHkt0KvpTPKhBfKydwfKD+uLpMqtIRDe9NTuFKAS8fyfkrUZnpnztl+Fc4TP?= =?us-ascii?Q?MBf5SBy9Rzyw6ZcbnfP/G5EQYQn4Ja00SMHJlR8J8HxaDQZeprfvVO3x4EuR?= =?us-ascii?Q?yPs4ZytrtVr7LP+EXT4NpOykh6YxW29FgmVQBnN5jACGRu3ylbrNUZbTZBlk?= =?us-ascii?Q?gGDw6UUtMoX6BCWT3qCE+TSInSorlk9POzvW8GXtbc0SSlrCIM8OpfyjiPEO?= =?us-ascii?Q?3QoZFRl1vs38LV+9uGR977MB0U8mtr44JbVSEcyMqlzoRqanbrdgcgolsTXq?= =?us-ascii?Q?6tWNpTPbGSfXIk/ew=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1119; 6:5xSvsHzOugV6D1tNAtvWkh6emIvQZtJkJdsitJH5sI52UQ4YXILJjAQltqWlgmwf469YCfgKxamtKBwt68PmkKVmFmmgN3swDekoGyPGCdxTP78BsIc+lIHWgCd3pPYdBa5izv94+S6QPuz3jdoRCzPgddUglRdr8vze8fA8AFWNuMt7+9CqVzSz24NtzgkbIwbtvSpq4bYKv8apP0mjuS04o+cDS+hQQCQNGrPzSa/WDNQ0nO2Y3dp3h5tRzg0TZ92GxX8icD4yZdmQC5fAadpThfaF37RAt8O1wPO+q4mavZOXKZcW+lGArF7yYVqEu3WvDcnFAOSQCpWXzX2bdA==; 5:SkSD9J87CbDS/sX7+xHbkcP40AEEI6x82x8zlFYSwkFdEQdXmPfpZYWXWNb7pbwJgh3HdLitQgqCO1AiXGhLhiVbEsgh9vFe/cBruO6asNPOlG6fWeJ7XG7oohmRdC5dk2U8eYDTEzeQlllaReEFyA==; 24:ItyqJi6l6P6lSHbJprR+HVV4xnpXfN1hdWWPS8ucLKyjljNtuGvkFadcc3sOBvFBQZGys09GLZi5jpp552Q/BUYCbBeqflf4trE9xzDbz2s=; 7:L0Z5QD6U670HammX6sqo6js4XuvWtS1m7Csx2FfPqdaPZkSnHIumKsJUTbUGpJqzNfzJM3TjSvrCNU4YBKgSw4yJ0YSbZCk3tMn+uObOszeCLoQl2f+mQ5pvYkFQKWeEK8VyQWul8Xs2Dc5q0rdOkPk12pMNaO34Q1S5G8PUCtqas6eOO84Air5UxeFNzykDLjYA+wOu/j7jt01G867bG1T6BvpNpGQgtVz7MGrs1v2XyjPteNy165YOKXtNYSScx31GHq4Ba8HxRrQYHBNI2pc06JZKMDvV8e7TSkUIRJomxaUs71GBBHTiiDCAGW8s SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2016 18:33:11.4260 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[40.103.22.100]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB1119 X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 40.103.22.100 X-MS-Exchange-CrossPremises-AuthSource: DB3FFO11FD043.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: VI1PR04MB1119.eurprd04.prod.outlook.com Archived-At: Subject: Re: [IPsec] Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 18:33:18 -0000 --_000_310149fca5cb4474b31d065becfffde2HE1PR9003MB0234MGDPHGem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott, this is a very interesting approach. Please, find below my feedback. Kind regards, Oscar. From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Scott Fluhrer (sfl= uhrer) Sent: Tuesday, September 06, 2016 5:10 PM To: IPsecme WG (ipsec@ietf.org) Subject: Re: [IPsec] Quantum Resistance Requirements Last month, I listed a series of potential requirements for a shortterm Qua= ntum Resistance solution; several people have commented on these requiremen= ts, and here are the votes so far (omitting the "no opinion" votes); I've l= isted the voters chiefly so that if I mischaracterized their votes, they ca= n correct me: From: Scott Fluhrer (sfluhrer) Sent: Thursday, August 11, 2016 6:01 PM To: IPsecme WG (ipsec@ietf.org) Subject: Quantum Resistance Requirements - Simplicity; how large of a change to IKE (and IKE implementation= s) are we willing to contemplate? Scott Fluhrer: very important Michael Richardson: very important Tommy Pauly: very important Valery Smyslov: not as important as other issues Oscar Garcia-Morchon: very important. o My opinion: minimizing changes to IKE should be given high priority, bo= th because "complexity is the enemy of security" and this is a short term s= olution; if we have a solution that we can't implement in a few years, well= , we might as well wait for the crypto people to give us the long term one. - Preserving existing IKE security properties? Scott Fluhrer: very important Michael Richardson: very important Tommy Pauly: very important Valery Smyslov: important Oscar Garcia-Morchon: very important. - What do we feel needs to protected from someone with a Quantum C= omputer? Do we feel the need to protect only the IPsec traffic, or do we = need to protect the IKE traffic as well. Tommy Pauly: not clear if IKE traffic needs to be protected. Valery Smylsov: important Oscar Garcia-Morchon: it seems to me that IPsec traffic is the most importa= nt one. If IKE traffic could be easily protected as well, this would be a n= ice addition. - What level of identity protection do we need to provide? If two= different IKE negotiations use the same shared secret, do we mind if someo= ne can deduce that? Scott Fluhrer: not important Michael Richardson: very important Tommy Pauly: not important Valery Smylsov: this is a nice to have, but not critical Oscar Garcia-Morchon: this is less important, in particular if we only prot= ect the IPsec traffic. - PPK management; how much support do we provide for automaticall= y managing the secrets? Scott Fluhrer: not important Tommy Pauly: not important Oscar Garcia-Morchon: not important. - How much support do we provide for nonstatic secrets, for exampl= e, by QKD, or via something like HIMMO (a key distribution mechanism that a= ppears to be post quantum)? Scott Fluhrer: not important Michael Richardson: not important Tommy Pauly: not important Oscar Garcia-Morchon: not important at this stage, but it is very important= to have hook to easily support this capability in the future. - Authentication; if someone with a Quantum Computer can break the= DH in real time, do we care if he can act as a man-in-the-middle? Scott Fluhrer: not important Michael Richardson: important, provided that we don't run into the same iss= ues that IKEv1 PSKs ran into Tommy Pauly: not important Valery Smylsov: this would be nice to have Oscar Garcia-Morchon: less important, but nice to have and it could be easi= ly supported with little effort. - Algorithm agility; how important is it that we negotiate any cry= ptoprimitives involved? Scott Fluhrer: not important Tommy Pauly: not important Valery Smylsov: important Oscar Garcia-Morchon: less important. ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_310149fca5cb4474b31d065becfffde2HE1PR9003MB0234MGDPHGem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Scott,

 

this is a very interes= ting approach.

Please, find below my = feedback.

 

Kind regards, Oscar.

 

From: IPsec [m= ailto:ipsec-bounces@ietf.org] On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Tuesday, September 06, 2016 5:10 PM
To: IPsecme WG (ipsec@ietf.org)
Subject: Re: [IPsec] Quantum Resistance Requirements

 

Last month, I listed a series of potential requirements for a shortte= rm Quantum Resistance solution; several people have commented on these requ= irements, and here are the votes so far (omitting the “no opinion” votes); I’ve listed the voter= s chiefly so that if I mischaracterized their votes, they can correct me:

 

From: Scott Fl= uhrer (sfluhrer)
Sent: Thursday, August 11, 2016 6:01 PM
To: IPsecme WG (ipsec@ietf.org= )
Subject: Quantum Resistance Requirements

 

 

-     &= nbsp;    Simplicity; how large of a change to IKE (and IKE i= mplementations) are we willing to contemplate?

Scott Fluhrer: very im= portant

Michael Richardson: ve= ry important

Tommy Pauly: very impo= rtant

Valery Smyslov: not as= important as other issues

Oscar Garcia-Morchon: = very important.

 

o   My opinion: minimizing changes to IKE should= be given high priority, both because “complexity is the enemy of sec= urity” and this is a short term solution; if we have a solution that = we can’t implement in a few years, well, we might as well wait for the crypto people to give us the long term one.

 

-   &= nbsp;      Preserving existing IKE security proper= ties?

Scott Fluhrer: very im= portant

Michael Richardson: ve= ry important

Tommy Pauly: very impo= rtant

Valery Smyslov: import= ant

Oscar Garcia-Morchon: = very important.

 

-     &= nbsp;    What do we feel needs to protected from someone wit= h a Quantum Computer?  Do we feel  the need to protect only the I= Psec traffic, or do we need to protect the IKE traffic as well.<= /p>

Tommy Pauly: not clear= if IKE traffic needs to be protected.

Valery Smylsov: import= ant

Oscar Garcia-Morchon: = it seems to me that IPsec traffic is the most important one. If IKE traffic= could be easily protected as well, this would be a nice addition.

 

-     &= nbsp;    What level of identity protection do we need to pro= vide?  If two different IKE negotiations use the same shared secret, d= o we mind if someone can deduce that?

Scott Fluhrer: not imp= ortant

Michael Richardson: ve= ry important

Tommy Pauly: not impor= tant

Valery Smylsov: this i= s a nice to have, but not critical

Oscar Garcia-Morchon: = this is less important, in particular if we only protect the IPsec traffic.=

 

-     &= nbsp;     PPK management; how much support do we provid= e for automatically managing the secrets?

Scott Fluhrer: not imp= ortant

Tommy Pauly: not impor= tant   

Oscar Garcia-Morchon: = not important.

 

-     &= nbsp;    How much support do we provide for nonstatic secret= s, for example, by QKD, or via something like HIMMO (a key distribution mec= hanism that appears to be post quantum)?

Scott Fluhrer: not imp= ortant

Michael Richardson: no= t important

Tommy Pauly: not impor= tant

Oscar Garcia-Morchon: = not important at this stage, but it is very important to have hook to easil= y support this capability in the future.

 

-     &= nbsp;    Authentication; if someone with a Quantum Computer = can break the DH in real time, do we care if he can act as a man-in-the-mid= dle?

Scott Fluhrer: not imp= ortant

Michael Richardson: im= portant, provided that we don’t run into the same issues that IKEv1 P= SKs ran into

Tommy Pauly: not impor= tant

Valery Smylsov: this w= ould be nice to have

Oscar Garcia-Morchon: = less important, but nice to have and it could be easily supported with litt= le effort.

 

-     &= nbsp;    Algorithm agility; how important is it that we nego= tiate any cryptoprimitives involved?

Scott Fluhrer: not imp= ortant

Tommy Pauly: not impor= tant

Valery Smylsov: import= ant

Oscar Garcia-Morchon: = less important.

 

 

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_310149fca5cb4474b31d065becfffde2HE1PR9003MB0234MGDPHGem_-- From nobody Wed Sep 21 14:23:33 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8AA12B71C for ; Wed, 21 Sep 2016 14:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.617 X-Spam-Level: X-Spam-Status: No, score=-6.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3CRLbgehztK for ; Wed, 21 Sep 2016 14:23:29 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B36AB12B614 for ; Wed, 21 Sep 2016 14:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1474493009; x=2338406609; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Za0QVPGk06rCMBkoQ+ghI3BIEJDFGAKvsIP2tYo+Dtc=; b=ImvlVsXvjHV61oMG7i0sN7Zy4t3b7VfCGKYzNFMyeZY54Vk8b17q8D9v7JxCayaZ uJKoqPKpISFDB+f76Z96KBBudQfuBDA2u3bXofo3VwPjK43z+5pdIFEPqq/kpOGt lVbuIF5b+DPeJomIkLPJHjbYg2CDt4dNPWTQUJzGkX4xcMWejgzGH230ByqkMaLa kLCfKN02Y0j1Prz3PVA5k7HSGPs9UOgYibeDHQmKeQJFJdQgiHA5vw0Ey9eWz1CH vZ0uXbW0Od+3Cio3cF39wJ1p2Muf/TycnNbwuUM5zqkc6KqScKqhKBaxuam3l7zb rYGCELdmTWXNp4tPbPBmbg==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id AF.AA.07433.15AF2E75; Wed, 21 Sep 2016 14:23:29 -0700 (PDT) X-AuditID: 11973e12-f79b16d000001d09-7c-57e2fa514ecc Received: from nwk-mmpp-sz06.apple.com (nwk-mmpp-sz06.apple.com [17.128.115.234]) by relay5.apple.com (Apple SCV relay) with SMTP id CA.EE.27929.15AF2E75; Wed, 21 Sep 2016 14:23:29 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_iEZN8K2Wp8QF36ltIafmsQ)" Received: from da0602a-dhcp170.apple.com (da0602a-dhcp170.apple.com [17.226.23.170]) by nwk-mmpp-sz06.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0ODV00EN2I34T700@nwk-mmpp-sz06.apple.com>; Wed, 21 Sep 2016 14:23:29 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Date: Wed, 21 Sep 2016 14:23:28 -0700 References: <147448964321.14590.5635818993002735779.idtracker@ietfa.amsl.com> To: IPsecME WG Message-id: <145AF2E4-1622-4177-89EC-FFDD146BEFD4@apple.com> X-Mailer: Apple Mail (2.3212) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUi2FAYoRv461G4wepfghb7t7xgs3h/6xKT A5PHkiU/mTy+z2MKYIrisklJzcksSy3St0vgypj0YC1zwWHPivuz7rI2MP5y6GLk5JAQMJGY M7eHDcIWk7hwbz2QzcUhJLCXUeL8vwbGLkYOsKKlL+Uh4ocYJaZPnMEE0sArICjxY/I9FhCb WSBM4mL3ArC4kMAyJonrM1RBeoUFJCQ270kECbMJqEgc/7aBGcQWFtCWWNN9HaycRUBVYvHO g4wQrb4SzUtes0GMVJQ4uOYoK8gYEQF5iZk3MiG22kice76YFeJkWYlFx6+wgpwmIXCETeJY 70nWCYxCs5BcNwvJdRC2lsT3R61AcQ4gW17i4HlZiLCmxLN7n9ghbG2JJ+8usC5gZFvFKJSb mJmjm5lnopdYUJCTqpecn7uJERQD0+2EdjCeWmV1iFGAg1GJh3dD76NwIdbEsuLK3EOM0hws SuK83W+BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgdNxW/N361f96E5E8mu/m+lJ6Qn1tr dL5UZw6brq1JXOUljRfpi18bP+h92C4/70YX74/OuZe/h8yJuHe5YTXvrSMMLXdWGsTtkP/Y WJ2+0ieJ/0qdKNP3hWJm50sCpyxmmKRcqOVrmmome/6uvp17cnS8jOxa8VddbatTOR+WCAgw yExYO02JpTgj0VCLuag4EQCjNbfPYgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUi2FD8Sjfw16NwgyeveC32b3nBZvH+1iUm ByaPJUt+Mnl8n8cUwBTFZZOSmpNZllqkb5fAlTHpwVrmgsOeFfdn3WVtYPzl0MXIwSEhYCKx 9KV8FyMnkCkmceHeerYuRi4OIYFDjBLTJ85gAknwCghK/Jh8jwXEZhYIk7jYvQAsLiSwjEni +gxVkDnCAhISm/ckgoTZBFQkjn/bwAxiCwtoS6zpvg5WziKgKrF450FGiFZfieYlr9kgRipK HFxzlBVkjIiAvMTMG5kQW20kzj1fzApxmqzEouNXWCcw8s9CctAsJAdB2FoS3x+1AsU5gGx5 iYPnZSHCmhLP7n1ih7C1JZ68u8C6gJFtFaNAUWpOYqWpXmJBQU6qXnJ+7iZGcMgWRuxg/L/M 6hCjAAejEg9vRPejcCHWxLLiylxgqHAwK4nw3vkBFOJNSaysSi3Kjy8qzUktPsQ4kRHox4nM UqLJ+cCIyiuJNzQxMTAxNjYzNjY3MaelsJI47zreB+FCAumJJanZqakFqUUwRzFxcEo1MFb9 n/g2/mi/qEigZ7TJ8RufFNzm/GB/rr9RPMKZXdWGw66g3Xlx8ZopTQ0HPs5babKw6V/Nq+Wy 8T7rG7e9llYTX/n/7WT9w1lxj3tW6y47qjTBivPs205R3virp3dp556azjN9OneBqk1DjpbV +Yp8VZM/U78tq76uvvR+yQTTbdmTvEV0XiixFGckGmoxFxUnAgD9wJkIzAIAAA== Archived-At: Cc: Paul Wouters Subject: [IPsec] New Version of Split DNS for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 21:23:32 -0000 --Boundary_(ID_iEZN8K2Wp8QF36ltIafmsQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hello all, We've posted a new version of draft-pauly-ipsecme-split-dns (https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02). The changes in this version include: - Textual clarification based on input from Daniel and Tero - Clarification of DNSSEC payload types - Update on the content and structure of the INTERNAL_DNSSEC_TA attribute - How to associate DNSSEC values with specific domains - Naming changes (IPSec -> IPsec, Split-DNS -> Split DNS) We believe this should be ready for adoption and moving forward, to follow the charter. Please review and provide your input! Thanks, Tommy > Begin forwarded message: > > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-pauly-ipsecme-split-dns-02.txt > Date: September 21, 2016 at 1:27:23 PM PDT > To: Tommy Pauly , Paul Wouters > > > A new version of I-D, draft-pauly-ipsecme-split-dns-02.txt > has been successfully submitted by Tommy Pauly and posted to the > IETF repository. > > Name: draft-pauly-ipsecme-split-dns > Revision: 02 > Title: Split DNS Configuration for IKEv2 > Document date: 2016-09-21 > Group: Individual Submission > Pages: 12 > URL: https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-split-dns-02.txt > Status: https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/ > Htmlized: https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02 > Diff: https://www.ietf.org/rfcdiff?url2=draft-pauly-ipsecme-split-dns-02 > > Abstract: > This document defines two Configuration Payload Attribute Types for > the IKEv2 protocol that add support for private DNS domains. These > domains should be resolved using DNS servers reachable through an > IPsec connection, while leaving all other DNS resolution unchanged. > This approach of resolving a subset of domains using non-public DNS > servers is referred to as "Split DNS". > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > --Boundary_(ID_iEZN8K2Wp8QF36ltIafmsQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
Hello all,

We've posted a new version of = draft-pauly-ipsecme-split-dns (https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02).

The = changes in this version include:

- Textual clarification based on input = from Daniel and Tero
- Clarification of DNSSEC = payload types
- Update on the content and = structure of the INTERNAL_DNSSEC_TA attribute
- How to = associate DNSSEC values with specific domains
- = Naming changes (IPSec -> IPsec, Split-DNS -> Split DNS)

We believe this should = be ready for adoption and moving forward, to follow the charter. Please = review and provide your input!

Thanks,
Tommy


Begin forwarded = message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-pauly-ipsecme-split-dns-02.txt
Date: = September 21, 2016 at 1:27:23 = PM PDT
To: = Tommy Pauly <tpauly@apple.com>, = Paul Wouters <pwouters@redhat.com>


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

Name: = draft-pauly-ipsecme-split-dns
Revision: 02
Title:= = Split DNS Configuration for IKEv2
Document = date: = 2016-09-21
Group: Individual Submission
Pages:= = 12
URL: =            https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-split-= dns-02.txt
Status: =         https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/=
Htmlized:       https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-pauly-ipsecme-split-d= ns-02

Abstract:
=   This document defines two Configuration Payload Attribute = Types for
  the IKEv2 protocol that add support = for private DNS domains.  These
  domains = should be resolved using DNS servers reachable through an
=   IPsec connection, while leaving all other DNS resolution = unchanged.
  This approach of resolving a = subset of domains using non-public DNS
=   servers is referred to as "Split DNS".




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

The IETF Secretariat


= --Boundary_(ID_iEZN8K2Wp8QF36ltIafmsQ)-- From nobody Thu Sep 22 08:14:47 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD1612B825 for ; Thu, 22 Sep 2016 08:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XP0uZaFh0dWI for ; Thu, 22 Sep 2016 08:14:44 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1BF12B6BE for ; Thu, 22 Sep 2016 08:14:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6CD16300A15 for ; Thu, 22 Sep 2016 11:14:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2DMuQ6B51mM7 for ; Thu, 22 Sep 2016 11:14:42 -0400 (EDT) Received: from [10.85.3.71] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id 34D4130056C for ; Thu, 22 Sep 2016 11:14:42 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_8B7D0E80-CC59-4660-9EBD-B28786D49D25" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Thu, 22 Sep 2016 11:14:40 -0400 References: <29427d45853b4e01b6e38674f8570721@XCH-RTP-006.cisco.com> <310149fca5cb4474b31d065becfffde2@HE1PR9003MB0234.MGDPHG.emi.philips.com> To: IETF IPsec In-Reply-To: <310149fca5cb4474b31d065becfffde2@HE1PR9003MB0234.MGDPHG.emi.philips.com> X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [IPsec] Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 15:14:46 -0000 --Apple-Mail=_8B7D0E80-CC59-4660-9EBD-B28786D49D25 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I would like to weigh in on this point. > - What level of identity protection do we need to provide? = If two different IKE negotiations use the same shared secret, do we mind = if someone can deduce that? > Scott Fluhrer: not important > Michael Richardson: very important > Tommy Pauly: not important > Valery Smylsov: this is a nice to have, but not critical > Oscar Garcia-Morchon: this is less important, in particular if we only = protect the IPsec traffic. I think it would be nice to have, but only if the cost is very low. I = prefer disclosure of a key identifier to having to perform a whole = series of key derivations until one is successful. Russ --Apple-Mail=_8B7D0E80-CC59-4660-9EBD-B28786D49D25 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = would like to weigh in on this point.

-          What level of = identity protection do we need to provide?  If two different IKE = negotiations use the same shared secret, do we mind if someone can = deduce that?
Scott Fluhrer: not important
Michael Richardson: very important
Tommy Pauly: not important
Valery Smylsov: this is a nice to have, but not = critical
Oscar Garcia-Morchon: this is less important, in particular if we = only protect the IPsec = traffic.

I think it would be = nice to have, but only if the cost is very low.  I prefer = disclosure of a key identifier to having to perform a whole series of = key derivations until one is = successful.

Russ

= --Apple-Mail=_8B7D0E80-CC59-4660-9EBD-B28786D49D25-- From nobody Thu Sep 22 17:42:56 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B68C12BF70; Thu, 22 Sep 2016 17:42:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147459137010.22414.18089918029174371097.idtracker@ietfa.amsl.com> Date: Thu, 22 Sep 2016 17:42:50 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-14.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 00:42:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Algorithm Implementation Requirements and Usage Guidance for IKEv2 Authors : Yoav Nir Tero Kivinen Paul Wouters Daniel Migault Filename : draft-ietf-ipsecme-rfc4307bis-14.txt Pages : 18 Date : 2016-09-22 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updates RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 22 17:45:53 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5589812B81D for ; Thu, 22 Sep 2016 17:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.316 X-Spam-Level: X-Spam-Status: No, score=-4.316 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=-2.316] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPiH4h6KnwXJ for ; Thu, 22 Sep 2016 17:45:50 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FEFA12BF71 for ; Thu, 22 Sep 2016 17:45:31 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sgF5P0dmXzN1x for ; Fri, 23 Sep 2016 02:45:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1474591529; bh=DoGQH4gKptezIJa4zUIOwzZc/0lIO+sguBzINcYfITU=; h=Date:From:To:Subject:In-Reply-To:References; b=esJOYcSNcb7ICU92WCWvBuC7cC7qz7xJOSvW2+eLftJ+QOm/qUqy+tB8v4WIiMifT HBTsUo+xujhRNwfoNrWcRqkV8p/YhDEKVmNifHbEnS0YeouvVQT2olfusi9p6v4Nya Yr7fm/2et9Vu1oGTDovmxxMNZbEI5kED7ZJf9c20= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id BEWOE7coEK9d for ; Fri, 23 Sep 2016 02:45:27 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Fri, 23 Sep 2016 02:45:27 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id EDF823797CE; Thu, 22 Sep 2016 20:45:24 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca EDF823797CE Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E82B24240F8E for ; Thu, 22 Sep 2016 20:45:24 -0400 (EDT) Date: Thu, 22 Sep 2016 20:45:24 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <147459137010.22414.18089918029174371097.idtracker@ietfa.amsl.com> Message-ID: References: <147459137010.22414.18089918029174371097.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-14.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 00:45:51 -0000 On Thu, 22 Sep 2016, internet-drafts@ietf.org wrote: > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-14.txt > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-14 These are the changes based on Valery's feedback. Paul ps. I hope Valery will assist me when testsuites or testlabs ask me why libreswan does not support PRF != INTEG :P From nobody Thu Sep 22 19:37:39 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C904A12B811 for ; Thu, 22 Sep 2016 19:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0snLkUo1uCKV for ; Thu, 22 Sep 2016 19:37:36 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D24112B800 for ; Thu, 22 Sep 2016 19:37:36 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id 38so46918119qte.1 for ; Thu, 22 Sep 2016 19:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hgtcUEXQ0UpkP/3AaMbaFv2LuTdRODz7j91ijDLqbPo=; b=D4M48uQkW0RdlJcG/Yb8D6MRTEl4tlbyljmnxoycVfyti+8oDq50JZjIQQV4dfbiuJ DlUQIbKxSY8AHl4TlqES1xPgRPiR7u00MjQgh5IXK9AOLlYvA8YfCIRS6I+XUGKVIcEp G/ACzniCDEmsaNeaxsVj8jEXvB/9n2/2PgXN3Jqtsa+lSiD/6xYbt6ExitHisfbWp+SD QhtSsItqRUlkiDN1pu3qnPO8Y1D5KhMao5DbA61H1+jCwLrfl+d8SUnxZFLm/x7mmqCr JgDgyieXUVF9pFaiAV280dLQ8T564QdBODBiWzMb6QlBTuL/ZyNKusrJRkQn+e3HNw9V lLiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hgtcUEXQ0UpkP/3AaMbaFv2LuTdRODz7j91ijDLqbPo=; b=EDasbjU7wyESS3FWQVpsdki20HuL4eM0qfWNTwtkbY1BHE72OTpMhiu8g6/iTb52RN lr50LZUObpeVP/EVfB92ZD5vjSUsslEqy8+jnDNeNwqYmwCcYWJun5+vW8rJPujjqpbQ MsFT2cMipYvo1CJlQcZEDFo4SbZjHgB+2e3awYiZ+j462BtRcBy8Pu3//V9VkUHwt9xY /XYRXVpXckLubMNiGNeq5YTC5W2v7nHni1ItaCSRyvo7JVseUyzNjcgt1+MRmUcbHlk5 8oO2Jnw4xZe7Te9Khy3X6eDQMsn0ZPypY50eVT5xQ7VJvAqtmSAxrcajsnAdmljTFHV9 lXHw== X-Gm-Message-State: AA6/9RkXUCcyWOHZz2KA+8rkHihClapOf3Fr0aqe+KBzufqGn+3+HUiCvXGPwt0drqIgCA== X-Received: by 10.200.46.76 with SMTP id s12mr5247986qta.126.1474598255107; Thu, 22 Sep 2016 19:37:35 -0700 (PDT) Received: from [192.168.1.3] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id g63sm2624052qkf.47.2016.09.22.19.37.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 22 Sep 2016 19:37:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G36) In-Reply-To: Date: Thu, 22 Sep 2016 22:37:33 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <147459137010.22414.18089918029174371097.idtracker@ietfa.amsl.com> To: Paul Wouters Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-14.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 02:37:38 -0000 Please excuse typos, sent from handheld device > On Sep 22, 2016, at 8:45 PM, Paul Wouters wrote: > >> On Thu, 22 Sep 2016, internet-drafts@ietf.org wrote: >> >> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-14.txt > >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-14 > > These are the changes based on Valery's feedback. Thank you, Paul. > > Paul > ps. I hope Valery will assist me when testsuites or testlabs ask me why > libreswan does not support PRF != INTEG :P > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Sep 23 12:11:44 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCC212B494; Fri, 23 Sep 2016 12:11:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147465789941.20366.13358533684157949770.idtracker@ietfa.amsl.com> Date: Fri, 23 Sep 2016 12:11:39 -0700 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, david.waltermire@nist.gov Subject: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-ipsecme-ddos-protection-09=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 19:11:39 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-ipsecme-ddos-protection-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some questions: 1) sec 7.1.2: If there is a puzzle but no cookie, maybe the initiator should ignore it and try to send reply without the puzzle solution, as there might be still a change to get served…? If it then received another packet with puzzle it can still solve it and reply. 2) sec 7.1.4: Does „the Responder MUST verify the puzzle solution“? Maybe there are cases where the burden for the initiator is high enough by requesting the solution that there is already an effect even if the responder decides to not verify it…? 3) also sec 7.1.4: Does the following sentence really makes sense? How doe the responser know? Maybe just remove it? „The more time the Initiator spent solving the puzzles, the higher priority it should receive.“ 4) sec 7.2.1.1 says „the Responder would be able to estimate the computational power of the Initiator and select the difficulty level accordingly.“ How would it estimate the computational power? Based on the reply time? Wouldn’t it also need to know the RTT and current congestion level then? 5) sec 7.2.2 says „If the IKE_SA_INIT response message contains the PUZZLE notification and the Initiator supports puzzles, it MUST solve the puzzle.“ Should this be „IKE_SA_AUTH“ here instead of „IKE_SA_INIT“? Otherwise it contradicts sec 7.1.2 („The Initiator MAY ignore the PUZZLE notification…“) Two general comments/questions: 1) What’s about the additional cpu load of the responder to calculate the puzzle. Can that be a problem? Are there any strategies to keep that low (recalculation/caching/reuse)? How long should things be cached/used? Maybe add a few sentences in the Operational Considerations section! 2) Would it make sense to also give a field to change the number of requested keys to scale load? Or why was it decided to use a fixed number of 4 here? From nobody Fri Sep 23 13:06:19 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA4B12B2FB; Fri, 23 Sep 2016 13:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rBxDv-EQWBT; Fri, 23 Sep 2016 13:06:14 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D2612B2DC; Fri, 23 Sep 2016 13:06:10 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id l132so51271377wmf.0; Fri, 23 Sep 2016 13:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iJAfW2IMj11Ps14SHH3T4K7cCxMieXCQo+10fgFTiCk=; b=yDaK8XJxTlFf7wG8YY5dbXTbLb9VQXdhz4KxdgNKGon4OTG8yPnCVSd5cpspBbhmcA Xk1Cjy6iCdqX5ZQ1gUYwzLfzP6u3zUgUVz/FHq20W5fvnrdDXH1jagHsIk4AeKKEcZCT b5nW/4ll6Ys5xR0ZX6y0NaYasnm8lke7wO/gZrm3G0+cuVeAsa9npo7h2sGPKuYNXLhY MTZOUhvsRfqGj5V37i0/el1X9OHqD93SDqVeY21FaAIf1odh2kp1kfMxb3G3gOX6Nnxp DiwJM7gVKND6Gd3wTvpvyn7FxEOCE1pB/dxc0D5qPHLjiIzzVQ2TLQe10qQgAGk/csm0 My9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iJAfW2IMj11Ps14SHH3T4K7cCxMieXCQo+10fgFTiCk=; b=eE44efxe8L3B6MY2l++12Yk3K1v1liBNKhDIdI8HaW2TgioVrx6LIDyKuavAJEBgAi GG4ty/bVlbVzk70Y6quO26mas5fArF++CDlha3CVI03j61gyZP6Jm1+Ter8hjrGiP2bH l4fs9yHHow7I1jDubWrRp64WA0gnK8whuDMiZWyAYMYzIzuOYC6Wm8we87P5I6Ej4RtE bMp42Dqe+RDemNNO74fZToHMMuRFPhdLhiQ86aKd4ZrSlYItTgEY9jcaWP0kGmqE/rWy NqCkO9+AWo16Hr974MahwZuJTUduG8FB2OIv+lf6cQdYNmbHrMTG9x31N9VTMi4FEa7z CHJQ== X-Gm-Message-State: AA6/9RlfRX99G9+3IyaECe4NxHju5XTpfxDdQKWcCn5d77BhZmHeAsqtsRs9HUiv/VuSDg== X-Received: by 10.28.137.18 with SMTP id l18mr4232789wmd.70.1474661168593; Fri, 23 Sep 2016 13:06:08 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 137sm4656713wmi.16.2016.09.23.13.06.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 23 Sep 2016 13:06:07 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <147465789941.20366.13358533684157949770.idtracker@ietfa.amsl.com> Date: Fri, 23 Sep 2016 23:06:05 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <674D263A-4EF8-4F8A-8320-1224FABAD10C@gmail.com> References: <147465789941.20366.13358533684157949770.idtracker@ietfa.amsl.com> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, The IESG , David Waltermire Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-ipsecme-ddos-protection-09=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 20:06:16 -0000 Hi. See responses below > On 23 Sep 2016, at 10:11 PM, Mirja Kuehlewind = wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Some questions: >=20 > 1) sec 7.1.2: If there is a puzzle but no cookie, maybe the initiator > should ignore it and try to send reply without the puzzle solution, as > there might be still a change to get served=E2=80=A6? If it then = received another > packet with puzzle it can still solve it and reply. A response that contains neither COOKIE nor INVALID_KE_PAYLOAD nor the = regular payloads like SA is invalid according to RFC 7296. That is one = reason why we chose to keep the COOKIE notification and add a PUZZLE = notification rather than put both pieces of data in the new = notification. A response with only PUZZLE and no COOKIE is invalid and = should be treated as such. So after some (not specified anywhere) time, = the Initiator should start a new IKE_SA_INIT exchange, hoping that this = time the Responder returns a valid response. >=20 > 2) sec 7.1.4: Does =E2=80=9Ethe Responder MUST verify the puzzle = solution=E2=80=9C? Maybe > there are cases where the burden for the initiator is high enough by > requesting the solution that there is already an effect even if the > responder decides to not verify it=E2=80=A6?=20 There was a suggestion discussed that the Responder MAY choose not to = check the solution or randomly check just one of the four solutions. The = WG didn=E2=80=99t like that as it makes the protocol non-deterministic = and makes things harder to test. So consensus was to make the = verification mandatory. Of course, this doesn=E2=80=99t affect = interoperability, so we can=E2=80=99t force a responder to check = everything. > 3) also sec 7.1.4: Does the following sentence really makes sense? How > doe the responser know? Maybe just remove it? > =E2=80=9EThe more time the Initiator spent solving the puzzles, = the higher > priority it should receive.=E2=80=9C The Responder cannot know. It can only assume based on the expected = number of steps in finding a solution with a certain number of trailing = zero bits. > 4) sec 7.2.1.1 says =E2=80=9Ethe Responder would be able to estimate = the > computational power of the Initiator and select the difficulty level > accordingly.=E2=80=9C How would it estimate the computational power? = Based on the > reply time? Wouldn=E2=80=99t it also need to know the RTT and current = congestion > level then? The only estimate that the responder has is based on what the initiator = solved during the IKE_SA_INIT exchange. If the Initiator solved a = level-15 puzzle (15 trailing zeros in each of the four solutions) then = it stands to reason that it *can* solve a level-15 puzzle. Maybe the = word =E2=80=9Cestimate=E2=80=9D is misleading here. > 5) sec 7.2.2 says =E2=80=9EIf the IKE_SA_INIT response message = contains the > PUZZLE notification and the Initiator supports puzzles, it MUST solve = the > puzzle.=E2=80=9C > Should this be =E2=80=9EIKE_SA_AUTH=E2=80=9C here instead of = =E2=80=9EIKE_SA_INIT=E2=80=9C?=20 > Otherwise it contradicts sec 7.1.2 (=E2=80=9EThe Initiator MAY = ignore the PUZZLE > notification=E2=80=A6=E2=80=9C) Sure. Seems to be a typo. > Two general comments/questions: >=20 > 1) What=E2=80=99s about the additional cpu load of the responder to = calculate the > puzzle. Can that be a problem? Are there any strategies to keep that = low > (recalculation/caching/reuse)? How long should things be cached/used? > Maybe add a few sentences in the Operational Considerations section! Verifying a puzzle solution involves 4 invocation of a MAC function on a = few tens of bytes. This is very low considering that (1) IKE initiation = involves at least one and typically two PK operations, and (2) IKE is = for generating key material which is then used to MAC millions or = billions of packets. > 2) Would it make sense to also give a field to change the number of > requested keys to scale load? Or why was it decided to use a fixed = number > of 4 here? You scale the load by changing the difficulty (number of requested = trailing zero bits). The reason we are asking for 4 solutions rather = than 1 is to make the amount of work more predictable. We could make it = even more predictable with 16 solutions, but that makes the packet = bigger and runs the risk of requiring packet fragmentation. So we chose = 4 as a reasonable compromise. See this mail about it: https://mailarchive.ietf.org/arch/msg/ipsec/v7PFBEWeaT6ZQCjzCmIaxbRnZ8A Yoav From nobody Fri Sep 23 15:37:21 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE9112BEC5 for ; Fri, 23 Sep 2016 15:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.218 X-Spam-Level: X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6FOFN2_XFr4 for ; Fri, 23 Sep 2016 15:37:10 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695B212BEBF for ; Fri, 23 Sep 2016 15:37:10 -0700 (PDT) Received: (qmail 21598 invoked from network); 24 Sep 2016 00:37:08 +0200 Received: from p5dec2ba0.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.43.160) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 24 Sep 2016 00:37:08 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <674D263A-4EF8-4F8A-8320-1224FABAD10C@gmail.com> Date: Sat, 24 Sep 2016 00:37:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <42C67A26-2DA3-46F4-A85F-2EE2E639D734@kuehlewind.net> References: <147465789941.20366.13358533684157949770.idtracker@ietfa.amsl.com> <674D263A-4EF8-4F8A-8320-1224FABAD10C@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, The IESG , David Waltermire Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-ipsecme-ddos-protection-09=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 22:37:13 -0000 Hi Yoav, okay. I guess some of the reasoning you gave could go into the draft=E2=80= =A6 Thanks! Mirja > Am 23.09.2016 um 22:06 schrieb Yoav Nir : >=20 > Hi. >=20 > See responses below >=20 >> On 23 Sep 2016, at 10:11 PM, Mirja Kuehlewind = wrote: >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Some questions: >>=20 >> 1) sec 7.1.2: If there is a puzzle but no cookie, maybe the initiator >> should ignore it and try to send reply without the puzzle solution, = as >> there might be still a change to get served=E2=80=A6? If it then = received another >> packet with puzzle it can still solve it and reply. >=20 > A response that contains neither COOKIE nor INVALID_KE_PAYLOAD nor the = regular payloads like SA is invalid according to RFC 7296. That is one = reason why we chose to keep the COOKIE notification and add a PUZZLE = notification rather than put both pieces of data in the new = notification. A response with only PUZZLE and no COOKIE is invalid and = should be treated as such. So after some (not specified anywhere) time, = the Initiator should start a new IKE_SA_INIT exchange, hoping that this = time the Responder returns a valid response. >=20 >>=20 >> 2) sec 7.1.4: Does =E2=80=9Ethe Responder MUST verify the puzzle = solution=E2=80=9C? Maybe >> there are cases where the burden for the initiator is high enough by >> requesting the solution that there is already an effect even if the >> responder decides to not verify it=E2=80=A6?=20 >=20 > There was a suggestion discussed that the Responder MAY choose not to = check the solution or randomly check just one of the four solutions. The = WG didn=E2=80=99t like that as it makes the protocol non-deterministic = and makes things harder to test. So consensus was to make the = verification mandatory. Of course, this doesn=E2=80=99t affect = interoperability, so we can=E2=80=99t force a responder to check = everything. >=20 >> 3) also sec 7.1.4: Does the following sentence really makes sense? = How >> doe the responser know? Maybe just remove it? >> =E2=80=9EThe more time the Initiator spent solving the puzzles, = the higher >> priority it should receive.=E2=80=9C >=20 > The Responder cannot know. It can only assume based on the expected = number of steps in finding a solution with a certain number of trailing = zero bits. >=20 >> 4) sec 7.2.1.1 says =E2=80=9Ethe Responder would be able to estimate = the >> computational power of the Initiator and select the difficulty level >> accordingly.=E2=80=9C How would it estimate the computational power? = Based on the >> reply time? Wouldn=E2=80=99t it also need to know the RTT and current = congestion >> level then? >=20 > The only estimate that the responder has is based on what the = initiator solved during the IKE_SA_INIT exchange. If the Initiator = solved a level-15 puzzle (15 trailing zeros in each of the four = solutions) then it stands to reason that it *can* solve a level-15 = puzzle. Maybe the word =E2=80=9Cestimate=E2=80=9D is misleading here. >=20 >> 5) sec 7.2.2 says =E2=80=9EIf the IKE_SA_INIT response message = contains the >> PUZZLE notification and the Initiator supports puzzles, it MUST solve = the >> puzzle.=E2=80=9C >> Should this be =E2=80=9EIKE_SA_AUTH=E2=80=9C here instead of = =E2=80=9EIKE_SA_INIT=E2=80=9C?=20 >> Otherwise it contradicts sec 7.1.2 (=E2=80=9EThe Initiator MAY = ignore the PUZZLE >> notification=E2=80=A6=E2=80=9C) >=20 > Sure. Seems to be a typo. >=20 >> Two general comments/questions: >>=20 >> 1) What=E2=80=99s about the additional cpu load of the responder to = calculate the >> puzzle. Can that be a problem? Are there any strategies to keep that = low >> (recalculation/caching/reuse)? How long should things be cached/used? >> Maybe add a few sentences in the Operational Considerations section! >=20 > Verifying a puzzle solution involves 4 invocation of a MAC function on = a few tens of bytes. This is very low considering that (1) IKE = initiation involves at least one and typically two PK operations, and = (2) IKE is for generating key material which is then used to MAC = millions or billions of packets. >=20 >> 2) Would it make sense to also give a field to change the number of >> requested keys to scale load? Or why was it decided to use a fixed = number >> of 4 here? >=20 > You scale the load by changing the difficulty (number of requested = trailing zero bits). The reason we are asking for 4 solutions rather = than 1 is to make the amount of work more predictable. We could make it = even more predictable with 16 solutions, but that makes the packet = bigger and runs the risk of requiring packet fragmentation. So we chose = 4 as a reasonable compromise. See this mail about it: > = https://mailarchive.ietf.org/arch/msg/ipsec/v7PFBEWeaT6ZQCjzCmIaxbRnZ8A >=20 > Yoav >=20 From nobody Sun Sep 25 13:20:20 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4574612B01C; Sun, 25 Sep 2016 13:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgN8K6PFmmNG; Sun, 25 Sep 2016 13:20:17 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C003512B016; Sun, 25 Sep 2016 13:20:16 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id g62so125382143lfe.3; Sun, 25 Sep 2016 13:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=2q4sxxSFZcXqvWBlM5BkiCBVqYveQcVwpSjzRX8XOy8=; b=xv58uawxMR4T4Yi+rpT0t9ioaH9s61NJqPSCiFnxtfdt3PqFxKw4xZDHFFdns8zH/A TOo6vO1DDOXF7Xg7GTcDGox2IfYz05wIRbyFusroRl/U9ur7MzMzD0VMf2PAk+JkEgID b/NXE3BNzMiyXWxJMGrKCTIC4VuRdBxU0CRw9IfWjVxWROIiZ0pC1usIfkr0WWz4odu+ CTei7TAJPXrj6Qx3I1XY37245AcR8H4eSpAb63gKuuebLUiPRIGBDdsTDxW+xvy3iqnC 5pwpaZN5SidkKbZR+Tgj0ijawukjgSTBq8n0MfM7UuEiU6T+swftze9sGZkkSuxm+zJb YA3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=2q4sxxSFZcXqvWBlM5BkiCBVqYveQcVwpSjzRX8XOy8=; b=XD5ZdUkhLpx23CXlni58mxNiA2x5hCKqf4+2PpDTBvGCuwK2Jo2SrCBEBaKndWamP8 g48IO4uE1d+ft+FSNw3x6co7myhtYxS33TDiYLoqAYhuBYrIAZr1/SeOUOW3PWsN4ILS YbnOzkcuK60iHeP4cHpJotEacllK80MSsFXBf9sDDoxh2hxjfzMdIzIJnxm2w8+IaQkt 8s9uZHeHA/AwHIZrp8lWI0TmdLUHd68b5EQOhDBIzQQmY/k8iIl7UmeaWqIGooB0bSKX O8oARA5uT4Ik/kgCo9ez/dd666Cg+w0YYq8GuLOaXgVheLdNN8sIMtepmU83kzVa17/I wgUQ== X-Gm-Message-State: AE9vXwPxCehsMrS9AHF9I/3n14OkJMBWk/1x+aGIls8vfqtWd0bENH+bB8mcv2tB8++CCQ== X-Received: by 10.25.218.6 with SMTP id r6mr6826270lfg.111.1474834814426; Sun, 25 Sep 2016 13:20:14 -0700 (PDT) Received: from chichi (ppp83-237-161-125.pppoe.mtu-net.ru. [83.237.161.125]) by smtp.gmail.com with ESMTPSA id a19sm498934lfa.19.2016.09.25.13.20.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 25 Sep 2016 13:20:13 -0700 (PDT) Message-ID: <701DC5E23DC747588D7047D73A87D855@chichi> From: "Valery Smyslov" To: "Yoav Nir" , "Mirja Kuehlewind" References: <147465789941.20366.13358533684157949770.idtracker@ietfa.amsl.com> <674D263A-4EF8-4F8A-8320-1224FABAD10C@gmail.com> In-Reply-To: <674D263A-4EF8-4F8A-8320-1224FABAD10C@gmail.com> Date: Sun, 25 Sep 2016 23:20:12 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, The IESG , David Waltermire Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-ipsecme-ddos-protection-09=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2016 20:20:19 -0000 Hi Mirja, Yoav, I agree with Yoav's answers, just want to clarify a few things. See below (I removed the comments where I have nothing to add to Yoav's answers). > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Some questions: > > > > 1) sec 7.1.2: If there is a puzzle but no cookie, maybe the initiator > > should ignore it and try to send reply without the puzzle solution, as > > there might be still a change to get served…? If it then received another > > packet with puzzle it can still solve it and reply. > > A response that contains neither COOKIE nor INVALID_KE_PAYLOAD nor the regular payloads like SA is invalid according > to RFC 7296. > That is one reason why we chose to keep the COOKIE notification and add a PUZZLE notification rather than put both > pieces of > data in the new notification. A response with only PUZZLE and no COOKIE is invalid and should be treated as such. > So after some (not specified anywhere) time, the Initiator should start a new IKE_SA_INIT exchange, hoping that this > time the > Responder returns a valid response. Actually, the Initiator sends requests, not responses. So, if the Initiator ignores invalid response from the Responder, then the only thing it can do is to wait some time and sends another request (or just retransmit the sent request in hope that invalid response was from an attacker who wants to break IKE SA establishment). If the situation doesn't improve (the Initiator continues to receive invalid responses), then the Initator has nothing to do but give up. I just want to emphasise that Mirja's suggestion (ignore invalid response) is exactly what the draft suggests to do in this case, as Yoav correctly outlined. Isn't it clear enough from the document? Should we add more clarifications? > > 3) also sec 7.1.4: Does the following sentence really makes sense? How > > doe the responser know? Maybe just remove it? > > „The more time the Initiator spent solving the puzzles, the higher > > priority it should receive.“ > > The Responder cannot know. It can only assume based on the expected number of steps in finding a solution with a > certain number of trailing zero bits. The Responder can also measure the time between the puzzle request and the reception of puzzle solution (and the Responder can do this in a stateless manner). Sure this measurment cannot be accurate, because it includes RTT, but it can be used as additional input to the prioritizing algorithm (along with puzzle difficulty and the number of times the puzzle was requested). But in general the prioritizing algorithm is a local matter of Responder and the draft doesn't mandatae it in any way. > > 5) sec 7.2.2 says „If the IKE_SA_INIT response message contains the > > PUZZLE notification and the Initiator supports puzzles, it MUST solve the > > puzzle.“ > > Should this be „IKE_SA_AUTH“ here instead of „IKE_SA_INIT“? > > Otherwise it contradicts sec 7.1.2 („The Initiator MAY ignore the PUZZLE > > notification…“) > > Sure. Seems to be a typo. No, that's not a typo. Note, that unlike IKE_SA_INIT exchange the IKE_AUTH exchange cannot be restarted. So, if we want the puzzle solution to be in IKE_AUTH request (that is sent by the Initiator), the puzzle must be given to the Initiator earlier, i.e. in the preceding response from the Responder, i.e. in the IKE_SA_INIT response. So the text is correct. However, I understand Mirja's source of confusion - in IKEv2 there are three different kinds of IKE_SA_INIT responses ("regular", COOKIE and INVALID_KE_PAYLOAD) and unfortunately RFC7296 doesn't give them distinct names - they all are IKE_SA_INIT response. So, there is no contradiction with 7.1.2, because 7.1.2 tells about IKE_SA_INIT response that contain COOKIE request (and PUZZLE request), while 7.2.2 tells about "regular" IKE_SA_INIT response, i.e. that contains SA, KE, NONCE payloads etc. So, while in the first case the Initiator can ignore puzzle request (if PUZZLE is present in a response containing COOKIE) and still have a chance to be served, in the second case it cannot ignore puzzle request (when PUZZLE is present in a "regular" IKE_SA_INIT response). Do you think it is not clear enough and more clarifications are needed? Regards, Valery. From nobody Sun Sep 25 13:29:04 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E81312B01C for ; Sun, 25 Sep 2016 13:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCb2EnI3Mx1H for ; Sun, 25 Sep 2016 13:29:01 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350D012B016 for ; Sun, 25 Sep 2016 13:29:01 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id l131so126068690lfl.2 for ; Sun, 25 Sep 2016 13:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-transfer-encoding:importance; bh=MAYTOPwdcEIwAbpxz9UMb8sG8TlRUQVVmCX/bd8KKVA=; b=HxPt3nVyim7etDKKYjrX/g6P2fdpJx4l5KQ/N1p5k/Lcfs3wIkjDe53Ke+znwRt4WI AmuBhUW290fjNOrqv+V9xQEZ/TO06ODmGE7a+Z4eBlScS+0Uc0h90xj8w/tFM+zKzbpl +zStCw2FepiO1M0yu4IgizACFDVKqWJ/Zvr8UD0FoZMgZE0UTPfXJHJs+XPkwntNm0yi CodmqLNu6gJCrhsmYQo88Z9lzpjtVXZ/SuPaBAqMoKn0MIFdGy4mB3wGuGSkKx3ZkQiQ 30D8AnblETv70jHJb2nq03AoQkFiiFpT1rtMlo+l5AP/rI+Klv5+e/MkqrXYoUIwSnO8 weFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=MAYTOPwdcEIwAbpxz9UMb8sG8TlRUQVVmCX/bd8KKVA=; b=VqTw0ZPIC3Bs00XCWAQrvs5IboQmkVqSHJnYYtsOWY/L66l0XqmP47h8lH+qjTXZGr 1seITXw+65kjHh+dZqx0RM+x69jS2PpQW+NFKMzLoiE6SpFh9bzthCdVEsDi4p6OBhZa +PgS2dJk+wqf+jL5xlcDsrKmC6Dtbl/xrwYq4jWkTxTEBHT16KqAXpOfqmCY05THvVIJ VLiyMFF7RYPPI0JWXeTfIhG5efUihqHCWKTL7r///LWoDv0RQtKI8L75N5YOQahQnrWg GLAjIbyC1+NzLcXlF2nyQZbLVYhT1XUdlxXttM6FAFUi/FqVTPlrkVdAZ3A6ZTBJmNyE QdwQ== X-Gm-Message-State: AE9vXwM8fIxkd7KjWB7E2bmx/PlRPXMkId2wetHehltx5Wzh1bYlQv7J87AOw3rcW9Mo0A== X-Received: by 10.25.15.206 with SMTP id 75mr6041711lfp.62.1474835339386; Sun, 25 Sep 2016 13:28:59 -0700 (PDT) Received: from chichi (ppp83-237-161-125.pppoe.mtu-net.ru. [83.237.161.125]) by smtp.gmail.com with ESMTPSA id u2sm3107147lja.16.2016.09.25.13.28.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 25 Sep 2016 13:28:58 -0700 (PDT) Message-ID: <3E34C18CE853448289FD1627DC16E8B5@chichi> From: "Valery Smyslov" To: "Paul Wouters" , References: <147459137010.22414.18089918029174371097.idtracker@ietfa.amsl.com> In-Reply-To: Date: Sun, 25 Sep 2016 23:28:57 +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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-14.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2016 20:29:03 -0000 Hi, > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-14 > > These are the changes based on Valery's feedback. my concerns are resolved. Thank you, Valery. > Paul > ps. I hope Valery will assist me when testsuites or testlabs ask me why > libreswan does not support PRF != INTEG :P From nobody Mon Sep 26 00:13:38 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC2212B04F for ; Mon, 26 Sep 2016 00:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF5_3Y-yu_NX for ; Mon, 26 Sep 2016 00:13:35 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7AF12B036 for ; Mon, 26 Sep 2016 00:13:35 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id 192so42382185vkl.2 for ; Mon, 26 Sep 2016 00:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=WkKbNTpNLcfTO2lGtiBrltFmXF/Im/8pPug4og5HPMM=; b=TX06SaOfy5jPMqlu+DjuYINKgna/Rpa2kfYon3jCN4KVhPYYc6n0RcgXqI2RcpLKJU FU2KCAdzv7soqKU+K9+YWDoiWt6+tPupLXURytbOnZyO9EojqUeHKd03pvleJs5X1Gd/ k026AG0W2bH+cMVS5BDvdLL2fAoz0zaWXTN4sP7YzgRamL4TEZGNkE0ox/qRocdKUoaB mw7o4ONHrWh1O6KrKTwkrhWP2/aD7Jxmlwlxb83ghKRQEifJ/EeX9+de0OQAbIglkIre GJQPWmAf1Cj0hD0rek8accd36sTZQZWwgzxlYrCxjSmGs4dh8a/eXfWk4IP8SIjsYHbE iOCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WkKbNTpNLcfTO2lGtiBrltFmXF/Im/8pPug4og5HPMM=; b=Pd168AforQLeEij9PGrDWMg+qIGDnTU2x4tE9XO8OI+THLjBFJYXVLaAugHLgUWMvl usOXWgx0ysGZxBYM3LN/+lxO6UZq7JLF7W7cIi8OJZ/2TPqC94Teo2XtZLX+YSxYiWyS AJi69LjhTsxZqv4mzqIsgmt+Pgw4nXOr5HNaD0+RaGegeqlVkU5nsvDDtiMtKsdasR7P IhWWsot18CuCsQucRinplhZBhQKpOzPH9scZdqq/oAEZJV4TsZDzc1G1MG0UX3OyiBhG KRvmRg/zvok0YQxNxiU2lBrC6+Fg3x6qg3zJ23JJh2mps35zvz4ABVHq61oI6ls6BYS2 b3Gw== X-Gm-Message-State: AA6/9RnfwtrrImK1MozEIdAySoMy2u87rnR2JRn01JLc2qT8y/SKPr7QRNB0+VKfkgwStkA+7iGKy2xEmN4IAw== X-Received: by 10.31.11.1 with SMTP id 1mr7108753vkl.118.1474874014653; Mon, 26 Sep 2016 00:13:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.150.132 with HTTP; Mon, 26 Sep 2016 00:13:34 -0700 (PDT) From: Wang Jian Date: Mon, 26 Sep 2016 15:13:34 +0800 Message-ID: To: IPsecME Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [IPsec] Flexible multi-factor authentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 07:13:37 -0000 Hello, When I researched for VPN solution for my company, IPsec was not an option. Then IKEv2 was an option but yet met our requirements. We chose from several SSL VPNs which also support ESP or UDP transport. The key requirement IKEv2 doesn't meet is MFA functionality and flexibility. Also, split dns functionality is missing. The MFA we finally implemented is like 1. Users first authenticate themselves with username & password 2. according to the user's security group, another OTP authentication step is needed or not. For users that OTP is needed, OTP authentication is prompted or skipped if (the device,the user) tuple was authenticated recently (i.e. 24 hours) * We could not get unique device id, so IP address and username are used as the tuple. However we prefer to a generated permanent device id by vpn client, the device's manufacturer-assigned id (or derived hash if privacy is a concern), or time-limited http-cookie-like id generated and returned by authenticator. Our flexible 2FA authentication is implemented using RADIUS challenge. The principles are 1. username & password authentication is used to integrated with central user management. For ease of use, VPN client should be capable of store password securely in device 2. authenticator controls the remaining authentication steps, and decides which step should be done or be skipped. Current IKEv2 doesn't provide an EAP authentication method to support such flexible MFA use case. And in the new charter, there is no goal of the kind. IMHO, flexible MFA is most important for large scale enterprise deployment. Please add it as a goal. Regards, Wang Jian From nobody Mon Sep 26 03:35:38 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2352712B11F for ; Mon, 26 Sep 2016 03:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulJsgMehJ5Ua for ; Mon, 26 Sep 2016 03:35:34 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D52A12B11E for ; Mon, 26 Sep 2016 03:35:34 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id l132so144117984wmf.0 for ; Mon, 26 Sep 2016 03:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KjCIAiCRSAsREYPgT8PcjClpyUlQ5bjPVfD6jtuWE8Y=; b=jBXak97utCyfTvniSBq+T8mYAZGTUui2DK6j2DTvf6BW/MPpomFaIW0ygHcA1Uch0g DdHeazS4+n9SDGvkpCOo3HQYM/WZOKSJqg0BIlUFA6Vp6KJuZl0EFBCka3Up7kJDCxtT FMqWDWBF/HhzEJM2GUasqu4JwI+vQpGd0lnQDRGI5MCBu/WXD/Wl1affaZgMB7Hztd8l rPPuWKafS8++sqqIlwPL+vS8lVHcAfpup1luRUGOGgEoGnczX/fFHce35nvC+5sHLBH5 7RJRNtpCc/sEiBZk23o5kGlXqbd8R31rnAaJz528HJrJ7q+vz/fG9qNUsJxIsijKxvXT i5xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KjCIAiCRSAsREYPgT8PcjClpyUlQ5bjPVfD6jtuWE8Y=; b=MmuUZmwo+JGsJJ97JayUog4Q0TAExTjFgN8FNzC2y4qTvrl72zKSpRnor9ZLb+jxBx qhHRlMeRWg03/XhanSzVablYiAxhR8UJ9gC+F86/lsP10WDZq8v2KQA36rjO53u+YfTj Qe7M9MDw6x9hvjHII1+io+aAYD/yIUlgDOw9JTetrysLahpNPU/WArvK1pFg47AiE85S mj2gWBjI7FmKuHOfBRmFJ8sR49AXCZbmF4jiY5gAKw+34atELPy2+5CqUN1WXJFd9UU1 dmN42E7qfOUydd8hSc/Me39nSh3QbXd7KTV580Rox93WLMB5onw2tJde0Lff+Rl4mPa2 bRJQ== X-Gm-Message-State: AA6/9RnUst2pjItqZEVmyxQ6YwISPJOkqDEOKsDKmNqJIrLbgCn3Ewd+PGs2XXc58CN1SQ== X-Received: by 10.28.145.129 with SMTP id t123mr12774544wmd.64.1474886132877; Mon, 26 Sep 2016 03:35:32 -0700 (PDT) Received: from [172.24.250.172] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id jn7sm21699614wjb.5.2016.09.26.03.35.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 26 Sep 2016 03:35:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Mon, 26 Sep 2016 13:35:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Wang Jian X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPsecME Subject: Re: [IPsec] Flexible multi-factor authentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 10:35:37 -0000 Hi. It seems that what you are looking for is a generic way to transport = arbitrary strings from server to client and back again. While not specifically intended for that, both EAP-GTC and EAP-OTP = (types 6 and 5 respectively) have been (ab)used for that purpose. Not = sure if that has happened in the context of IKEv2, though. GTC in a = TTLS/PEAP/some other kind of tunneling has been done before, although = when running EAP in IKE I don=E2=80=99t think you need yet another = tunnel. I guess it depends on the level of pre-existing trust that = exists between the client and the VPN gateway (as opposed to the EAP = authentication server). Yoav > On 26 Sep 2016, at 10:13 AM, Wang Jian wrote: >=20 > Hello, >=20 > When I researched for VPN solution for my company, IPsec was not an > option. Then IKEv2 was an option but yet met our requirements. >=20 > We chose from several SSL VPNs which also support ESP or UDP > transport. The key requirement IKEv2 doesn't meet is MFA functionality > and flexibility. Also, split dns functionality is missing. >=20 > The MFA we finally implemented is like >=20 > 1. Users first authenticate themselves with username & password > 2. according to the user's security group, another OTP authentication > step is needed or not. For users that OTP is needed, OTP > authentication is prompted or skipped if (the device,the user) tuple > was authenticated recently (i.e. 24 hours) >=20 > * We could not get unique device id, so IP address and username are > used as the tuple. However we prefer to a generated permanent device > id by vpn client, the device's manufacturer-assigned id (or derived > hash if privacy is a concern), or time-limited http-cookie-like id > generated and returned by authenticator. >=20 > Our flexible 2FA authentication is implemented using RADIUS challenge. > The principles are >=20 > 1. username & password authentication is used to integrated with > central user management. For ease of use, VPN client should be capable > of store password securely in device > 2. authenticator controls the remaining authentication steps, and > decides which step should be done or be skipped. >=20 > Current IKEv2 doesn't provide an EAP authentication method to support > such flexible MFA use case. And in the new charter, there is no goal > of the kind. >=20 > IMHO, flexible MFA is most important for large scale enterprise > deployment. Please add it as a goal. >=20 > Regards, > Wang Jian >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Sep 26 11:50:05 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9683312B33A for ; Mon, 26 Sep 2016 11:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.316 X-Spam-Level: X-Spam-Status: No, score=-4.316 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=-2.316] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFCWWYWwztvB for ; Mon, 26 Sep 2016 11:50:02 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA8E012B202 for ; Mon, 26 Sep 2016 11:50:01 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sjY1J4DcMzWl; Mon, 26 Sep 2016 20:49:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1474915796; bh=OFXB3ktmsMsqIpqPM0abrDNfT7I/ppDIIWbISStnyF8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DLx+09wewEmsuFffrLKGDfPpguB5ijSSEhZXlf5d/8Av2NMNPw7Iz11UktvJBC7n7 O3fcwog+Y5BzBHUh+abk6n6iKvSNgUBQYSzvjPgzQextYSweEx48TANBSHnPN2myrr +w8KJV20CNKACMwm/giKfqMn+3sdir0e4DmM539U= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id VpUnjMsItCAq; Mon, 26 Sep 2016 20:49:54 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 26 Sep 2016 20:49:54 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id CD22035A2A7; Mon, 26 Sep 2016 14:49:51 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca CD22035A2A7 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B34E340D3581; Mon, 26 Sep 2016 14:49:51 -0400 (EDT) Date: Mon, 26 Sep 2016 14:49:51 -0400 (EDT) From: Paul Wouters To: Wang Jian In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME Subject: Re: [IPsec] Flexible multi-factor authentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 18:50:03 -0000 On Mon, 26 Sep 2016, Wang Jian wrote: > Also, split dns functionality is missing. You could help by reviewing and telling us you are in favour of working group adoption of: https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02 > Current IKEv2 doesn't provide an EAP authentication method to support > such flexible MFA use case. And in the new charter, there is no goal > of the kind. > > IMHO, flexible MFA is most important for large scale enterprise > deployment. Please add it as a goal. We dont really add goals that have no backers behind them. So if you want this process to start, the best way would be: 1) write a draft and publish it to the list for feedback (maybe ask for co-authors to help) 2) ask for working group adoption 3) get the document ready as per working group consensus Paul From nobody Tue Sep 27 01:48:59 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA6112B036 for ; Tue, 27 Sep 2016 01:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHBG2qFeJHsM for ; Tue, 27 Sep 2016 01:48:56 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECB1F12B018 for ; Tue, 27 Sep 2016 01:48:55 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id 192so6737684vkl.2 for ; Tue, 27 Sep 2016 01:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wldeyD7ZBLVABf1PwnRD2tzW0c9qlv6im/jcCztxsDM=; b=CPLczf0OM0lu2O/IsBA7hCIZzBZkzc0K1Ji7YSSiYuJv0SmV3VbQdEurT91xamB9iM 0HUAuSNg46evqupii4YhZ6mQW/YG7P1LVdWdqR/2GIDFHG9RxppyLoZLf8yNX5PEqtG+ 6qtR0PftgWEWnhGYccQT/QAE43q/DwSQj3u6svtyt351XwSN5VtCFQ5df8rXDZh93b3h jVBqxWmGW2SVlgN2cEWYOIuj3FtynArXFjEi9+QZPj6b51HebDr9wHIr1Z+IU7xM9NSX /yn5/gtN65BWzmVePnpDnTdpNN3iJx4y8N5c/+BUU8zBB051nCrWydza5e6Zthc4d14x eRHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wldeyD7ZBLVABf1PwnRD2tzW0c9qlv6im/jcCztxsDM=; b=PYYuMbxpskIKL7SSu3FiE1frz8Vs5qtqynenLJjguj8EQS+KhwDXVOAOVU25c2uDTE pafp/Y8GaLolD85JcgBEL/AFPBNlsBGYqZ79HbfpZ0qyCPW2bJ6CQicci/mWZYOm5jJA bziFdnz/sazG5SCayiuv5189k7ReSNL14vEg51h3KC/kLCGjHT/MlhzmUjJfnD+cauaa Ia2WZFXgnGSruR10cu0OqRZjId71RKHZD8s7S1IZv2YWpOmzWE+BN2VD4RnXCGHDMuk+ 3vNOHMGzWkEmVMg+ZSj2rQgoR1E7qNuHf6pgH0GdwzQJ55uE4mAWoHXzs0Sou37UIBgv gh0Q== X-Gm-Message-State: AA6/9RmEy9K+dYoECjG7aDFpx3yiCkT+CAfnlVSWFrhv+gej0fCHy/hfL9sH7vtWMYwp+CmPRbuYjltW+R7dKQ== X-Received: by 10.31.169.67 with SMTP id s64mr9917919vke.21.1474966135045; Tue, 27 Sep 2016 01:48:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.150.132 with HTTP; Tue, 27 Sep 2016 01:48:54 -0700 (PDT) In-Reply-To: References: From: Wang Jian Date: Tue, 27 Sep 2016 16:48:54 +0800 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPsecME , Jian Wang Subject: Re: [IPsec] Flexible multi-factor authentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 08:48:58 -0000 Hi, It's not only a generic way for authentication conversation, but also a defined way for authentication conversation. VPN clients, vpn servers and authentication servers must have a standard, thus unified user experiences. - What should be prompted to user during conversation, what should be interpreted by clients, servers, and AS. Examples * username and password authentication should be prompted to user if no credential saved, but quitely handled if credential saved; when username & password authentication fails, user is prompted to re-enter * TOTP authentication request by server should be prompted to user, a message and an input field, and client should not save the TOTP input * Fingerprint authentication request by server should be prompted to user and client should use fingerprint sensor (and handling timeout?) - Input data type: although all input data can be stringified, how to intepret them and how to handle them? TOTP number? human fingerprint? - How to distinguish failure or unsupported method, for example * fingerprint authentication is requested, but client replies that it doesn't support it. Then alternative method such as TOTP can be used Commercial SSL VPN vendors can ensure client, server and authentication server to be in accordance. I think IKEv2 as a standard, should also cover this area. EAP-OTP and EAP-GTC in EAP-TTLS can be abused, but if they are not abused the same way in clients, servers and authentication servers, can't be used at all for enterprise deployment. BTW: Can EAP-MD5/EAP-GTC/EAP-OTP be chained in EAP-TTLS in IKEv2? If yes, any pointer to docs, examples? Regards, Wang Jian 2016-09-26 18:35 GMT+08:00 Yoav Nir : > Hi. > > It seems that what you are looking for is a generic way to transport arbi= trary strings from server to client and back again. > > While not specifically intended for that, both EAP-GTC and EAP-OTP (types= 6 and 5 respectively) have been (ab)used for that purpose. Not sure if tha= t has happened in the context of IKEv2, though. GTC in a TTLS/PEAP/some oth= er kind of tunneling has been done before, although when running EAP in IKE= I don=E2=80=99t think you need yet another tunnel. I guess it depends on = the level of pre-existing trust that exists between the client and the VPN = gateway (as opposed to the EAP authentication server). > > Yoav > >> On 26 Sep 2016, at 10:13 AM, Wang Jian wrote: >> >> Hello, >> >> When I researched for VPN solution for my company, IPsec was not an >> option. Then IKEv2 was an option but yet met our requirements. >> >> We chose from several SSL VPNs which also support ESP or UDP >> transport. The key requirement IKEv2 doesn't meet is MFA functionality >> and flexibility. Also, split dns functionality is missing. >> >> The MFA we finally implemented is like >> >> 1. Users first authenticate themselves with username & password >> 2. according to the user's security group, another OTP authentication >> step is needed or not. For users that OTP is needed, OTP >> authentication is prompted or skipped if (the device,the user) tuple >> was authenticated recently (i.e. 24 hours) >> >> * We could not get unique device id, so IP address and username are >> used as the tuple. However we prefer to a generated permanent device >> id by vpn client, the device's manufacturer-assigned id (or derived >> hash if privacy is a concern), or time-limited http-cookie-like id >> generated and returned by authenticator. >> >> Our flexible 2FA authentication is implemented using RADIUS challenge. >> The principles are >> >> 1. username & password authentication is used to integrated with >> central user management. For ease of use, VPN client should be capable >> of store password securely in device >> 2. authenticator controls the remaining authentication steps, and >> decides which step should be done or be skipped. >> >> Current IKEv2 doesn't provide an EAP authentication method to support >> such flexible MFA use case. And in the new charter, there is no goal >> of the kind. >> >> IMHO, flexible MFA is most important for large scale enterprise >> deployment. Please add it as a goal. >> >> Regards, >> Wang Jian >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > From nobody Tue Sep 27 02:08:39 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4117C12B095 for ; Tue, 27 Sep 2016 02:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbVmCd9JUE62 for ; Tue, 27 Sep 2016 02:08:33 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D242212B0A9 for ; Tue, 27 Sep 2016 02:08:31 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id u68so5638846uau.1 for ; Tue, 27 Sep 2016 02:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ICKONBAOdHupuUw/gO5HtJ+yPPeKdzU89prBpDuEeig=; b=TOclW1/iy0vjwC3qwDRUeuknnv5jTID8tNCv7Sfav2PP+JwDlrmV33SE8SADixpGY8 5OIcmJ4D6li5urSJqsP0b5GRGrVsx0JhvnXBjqSb8GQTe5t2kNyRDzIUQ6qMtYZw0clR 4eAXEqx2prv1Q+43U+ttq24StDrjW2/4xAePil56vgdbz6czwNAnbxHJUiHc/2yUXePf fSrqEPOHNOZbATQEERjyLFrrFMDvmXNVzQpZ9TfQHXsAlbwzm2uhQdEHr/guWgsdS2cC Zv3Gn5kzVp+dqeUtH5/UYm/WhvAvI9NbYeZvMaR0ExKYn6QxUsWwcRW+8D3x9FTSzl0L bWIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ICKONBAOdHupuUw/gO5HtJ+yPPeKdzU89prBpDuEeig=; b=CrgjjTmfF2bEfjwCuHP3ViAG4Z+a2Lh9BLwZqI3pwebGm/OGkhlztwp0GHGVj8b3/r OJ/LJYzIHaoRKTYwWYPvr3DIDNqvlIsC1B4COyOSdFxt4i5P0IUxZLPg5GD240s7oNww sd0Vi6HKF2O11gLbRf6Pj26J2fu5blDWd8BlL3P+2p7M04daFoUZAj6nCVNW2r1Lij5S ZGOqDQc+cz8YemqqzCGtsXWntAq2iR5DvM6s/BRjCIqHg5qtMqnL1Pa0nfyIZ7iA4Jh5 0k9QhJMGOeiVfX7BnBEf4QmavbHWxNS00Vqc+EWNHbbiHt2ulsU9kEYcD6S1C7Wy5C4l pLng== X-Gm-Message-State: AA6/9RlYDBVBJuKR3oldFiAD9MDIbYVcbGpgm/kn+wRcl/vCixcYk7o8meTn5cXE6XMwoALGYm78Dq5TMiTymQ== X-Received: by 10.176.84.210 with SMTP id q18mr1990058uaa.44.1474967311008; Tue, 27 Sep 2016 02:08:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.150.132 with HTTP; Tue, 27 Sep 2016 02:08:30 -0700 (PDT) In-Reply-To: References: From: Wang Jian Date: Tue, 27 Sep 2016 17:08:30 +0800 Message-ID: To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPsecME , Jian Wang Subject: Re: [IPsec] Flexible multi-factor authentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 09:08:37 -0000 2016-09-27 2:49 GMT+08:00 Paul Wouters : > You could help by reviewing and telling us you are in favour of > working group adoption of: > > https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02 > I am new here. I will try. > We dont really add goals that have no backers behind them. So if you > want this process to start, the best way would be: > > 1) write a draft and publish it to the list for feedback > (maybe ask for co-authors to help) > 2) ask for working group adoption > 3) get the document ready as per working group consensus > I understand that. I will learn how to do these. First I need some help and suggestion to identify what area should be work on. For example, a new EAP type or generic EAP chaining mechanism? From nobody Tue Sep 27 03:15:38 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FCA12B0AE; Tue, 27 Sep 2016 03:15:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147497133669.20752.15148121845053327482.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 03:15:36 -0700 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, david.waltermire@nist.gov Subject: [IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 10:15:37 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-ipsecme-ddos-protection-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I tempted to ballot Yes on on the document. I hope it will get widespread deployment. Please excuse my ignorance: Puzzle Solution Payload format - I don't see the new payload type specified in the diagram. Where is it included? From nobody Tue Sep 27 04:44:31 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF4012B128; Tue, 27 Sep 2016 04:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.777 X-Spam-Level: X-Spam-Status: No, score=-3.777 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNuahIWgMHbs; Tue, 27 Sep 2016 04:44:21 -0700 (PDT) Received: from fish.elvis.ru (fish.elvis.ru [82.138.51.18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549D912B0FA; Tue, 27 Sep 2016 04:44:21 -0700 (PDT) Received: from [10.111.1.40] (helo=robin.office.elvis.ru) by fish.elvis.ru with esmtp (Exim 4.76) (envelope-from ) id 1boqmL-00081N-93; Tue, 27 Sep 2016 14:42:29 +0300 Received: from buildpc (10.111.10.31) by robin.office.elvis.ru (10.111.1.40) with Microsoft SMTP Server id 14.3.301.0; Tue, 27 Sep 2016 14:42:32 +0300 Message-ID: From: Valery Smyslov To: Alexey Melnikov , The IESG References: <147497133669.20752.15148121845053327482.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 14:42:26 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; 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: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, David Waltermire Subject: Re: [IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 11:44:24 -0000 Hi Alexey, payload type for the Puzzle Solution Payload is specified in the last sentence of Section 8.2: The payload type for the Puzzle Solution payload is . It is not included in the diagram in this section since the "Next Payload" field in generic payload header contains the type of the following payload, not the type of payload the diagram depicts. There is also an IANA Considerations Section which also specifies the payload type for the Puzzle Solution payload. Thank you, Valery Smyslov. > Alexey Melnikov has entered the following ballot position for > draft-ietf-ipsecme-ddos-protection-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I tempted to ballot Yes on on the document. I hope it will get widespread > deployment. > > Please excuse my ignorance: Puzzle Solution Payload format - I don't see > the new payload type specified in the diagram. Where is it included? From nobody Tue Sep 27 04:58:04 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF3A12B11B; Tue, 27 Sep 2016 04:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMXGOB0MCzNH; Tue, 27 Sep 2016 04:57:55 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F07412B120; Tue, 27 Sep 2016 04:48:26 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id l132so8575771wmf.1; Tue, 27 Sep 2016 04:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AhBW++7ac4bvj4QkHPbCB2OWjZfb0fRUWiWlF5rhvks=; b=NPjbVrwvYUb+9Q6AmYTumvbck/HxalRJGRN11pGcbOyzz0uRuy2NBR7Yr0YHjtNgxU jMOpoY+Cmf0ZqFfx6NPianM6eUSoL0RbVmTdKuYS2K6rxOmvxRNpkouZb6KBnKmURBPw o5zNGcsADtzYHFa7y7TymyMxes9shYDB398/gtDr5ZpHmVVFjHDjwihOVMVFZYug7rau Lqg1cggg7emN9GYSRdlh1UCt3D8rddpG7H/dwGlnd91EMcanoI++VO7q8mSGZ9wwRaS3 vRGIznE2UHzV1PL6b8R1hE5uB0ZQl4LUd8vk3c742yOrj6R2w3835Ca2O0A+p71O0k1M 3Zww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AhBW++7ac4bvj4QkHPbCB2OWjZfb0fRUWiWlF5rhvks=; b=Lk6KPrO2atyt3TuZeStTmk8rEgAqe8vtduhbX5hTpT1CYnTj9vtSeZbj1SP3fgegoE 4tKvUVhB6GjHv+in+YJ3mo1ICXENV2Nb2deTQmf77NGC3b1Aesk8ez81LQw/sPBPIQgI /Ro6Vn9kBC51uY+8meF3kF1oRJab40XBwpippYmUzlT1YxP86ah2+EgMlqulmC8MdX38 9C1ZvtfYBQxW0MzKq0uCI0XIQU5Yzgvm7CE6eA8Oa9QhKz4+8Tv9oZQbkOFwvzEFMjtD Eh+gVUUxUpjQPDuANQjo72UqgOJ7Mr9rWIH/CO8jF6jYaDKX6oq7gyjl2kfWiUE/RsHk zWSw== X-Gm-Message-State: AA6/9RkEfuqCB0RLr5qkgGJ/q0Zt5ctX9J6YkASLIm3JfyeBusQ7z7jknV+uP7UW7++KQw== X-Received: by 10.28.93.14 with SMTP id r14mr2540089wmb.89.1474976904648; Tue, 27 Sep 2016 04:48:24 -0700 (PDT) Received: from [172.24.250.172] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id e187sm2734152wma.21.2016.09.27.04.48.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 27 Sep 2016 04:48:24 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Yoav Nir X-Priority: 3 In-Reply-To: Date: Tue, 27 Sep 2016 14:48:21 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0E788477-59F6-4736-B87C-8D75A6A8915F@gmail.com> References: <147497133669.20752.15148121845053327482.idtracker@ietfa.amsl.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, Alexey Melnikov , ipsec@ietf.org, David Waltermire , The IESG Subject: Re: [IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 11:57:57 -0000 > On 27 Sep 2016, at 2:42 PM, Valery Smyslov wrote: >=20 > Hi Alexey, >=20 > payload type for the Puzzle Solution Payload is specified in the last = sentence > of Section 8.2: >=20 > The payload type for the Puzzle Solution payload is . >=20 > It is not included in the diagram in this section since the "Next = Payload" field in generic payload header contains the type of the = following payload, not the type of payload the diagram depicts. But it is depicted in sections 7.1.2 and 7.2.2. In both cases denoted as = PS (=3Dpuzzle solution): =46rom 7.1.2: If the Initiator supports puzzles and is ready to solve them, then it tries to solve the given puzzle. After the puzzle is solved the Initiator restarts the request and returns back to the Responder the puzzle solution in a new payload called a Puzzle Solution payload (denoted as PS, see Section 8.2) along with the received COOKIE notification. HDR, N(COOKIE), [PS,] SA, KE, Ni, [V+][N+] =E2=80=94> =46rom 7.2.2: If the IKE_SA_INIT response message contains the PUZZLE notification and the Initiator supports puzzles, it MUST solve the puzzle. Note, that puzzle construction in the IKE_AUTH exchange differs from the puzzle construction in the IKE_SA_INIT exchange and is described in Section 7.2.3. Once the puzzle is solved the Initiator sends the IKE_AUTH request message, containing the Puzzle Solution payload. HDR, PS, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SA, TSi, TSr} --> From nobody Tue Sep 27 07:15:45 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D961412B1DD; Tue, 27 Sep 2016 07:15:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147498573984.4422.6714124908866134362.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 07:15:39 -0700 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, david.waltermire@nist.gov Subject: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 14:15:40 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-ipsecme-ddos-protection-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "A typical Initiator or bot-net member in 2014 can perform slightly less than a million hashes per second per core" Is this supposed to say 2014? Struck me as a little weird. From nobody Tue Sep 27 09:08:14 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11BD12B283; Tue, 27 Sep 2016 09:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-2.316, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uPitz6LqWCk; Tue, 27 Sep 2016 09:08:11 -0700 (PDT) Received: from fish.elvis.ru (fish.elvis.ru [82.138.51.18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6CAC12B1A3; Tue, 27 Sep 2016 09:08:11 -0700 (PDT) Received: from [10.111.1.40] (helo=robin.office.elvis.ru) by fish.elvis.ru with esmtp (Exim 4.76) (envelope-from ) id 1boutg-0000IZ-N1; Tue, 27 Sep 2016 19:06:20 +0300 Received: from buildpc (10.111.10.31) by robin.office.elvis.ru (10.111.1.40) with Microsoft SMTP Server id 14.3.301.0; Tue, 27 Sep 2016 19:06:24 +0300 Message-ID: <7171B86D8F7147788E4DF649B1236F68@buildpc> From: Valery Smyslov To: Alissa Cooper , The IESG References: <147498573984.4422.6714124908866134362.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 19:06:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; 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: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, David Waltermire Subject: Re: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 16:08:13 -0000 Hi Alissa, > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "A typical Initiator or > bot-net member in 2014 can perform slightly less than a million > hashes per second per core" > > Is this supposed to say 2014? Struck me as a little weird. The -00 version of the document was written in 2014, so the estimates came from Yoav's experiments, that he conducted at that time, I think. Regards, Valery Smyslov. From nobody Tue Sep 27 10:09:52 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C539B12B24D; Tue, 27 Sep 2016 10:09:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147499618776.4465.11672584634820556976.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 10:09:47 -0700 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, david.waltermire@nist.gov Subject: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 17:09:48 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-ipsecme-ddos-protection-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is a nicely written document... thanks! - I vaguely recalled that puzzles and IPR rang a bell. Did the WG consider [1]? If not, and if it helps, I'm fine with making a 3rd party declaration on that and last call could be done again. Or maybe there's a better way to handle it. Or maybe the WG considered it and are happy enough already that it's not relevant or about to expire or abandoned or something. ("Not relevant" would puzzle me:-) [1] https://datatracker.ietf.org/ipr/417/ - section 3: "if certificates are involved" - you could note here that involving certificates can introduce a network based delay (OCSP, CRLs etc) that's a little different from CPU consumption. (But it's a nit, and you do note a similar issue in 4.7.) - 4.2: "ratelimits should be done based on either the /48 or /64" - would it be better to say "something between a /48 and a /64" maybe? Don't some ISPs assign things in-between? - 4.4: Did you consider making the "4 keys" requirement tied to the PRF algorithm identifier? That would allow for a future where e.g. 6 keys are needed for the same PRF, if that were ever useful. (Without changing current implementations.) I guess you'd need a separate IANA registry that'd initially duplicate stuff in that case so maybe not worth doing. (And could be done later.) - 7.1.1 - you don't clearly say if the cookie value here can be a new one or should be the same as one previously used (if one was previously used). That may just be my ignorance of IPsec cookies though, but I wondered if there are any cases where the initiator gets to work away on the puzzle ahead of time if the same cookie is used for multiple interactions. There's not much (or zero) of an improvement to the attack here, though maybe the attacker could more easily offload puzzle solving to someone else in that case? From nobody Tue Sep 27 12:09:26 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF01412B255; Tue, 27 Sep 2016 12:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.777 X-Spam-Level: X-Spam-Status: No, score=-3.777 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRo7MYyauY1V; Tue, 27 Sep 2016 12:09:16 -0700 (PDT) Received: from fish.elvis.ru (fish.elvis.ru [82.138.51.18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6FD127077; Tue, 27 Sep 2016 12:09:16 -0700 (PDT) Received: from [10.111.1.40] (helo=robin.office.elvis.ru) by fish.elvis.ru with esmtp (Exim 4.76) (envelope-from ) id 1boxj5-0000e2-MS; Tue, 27 Sep 2016 22:07:35 +0300 Received: from chichi (10.100.101.1) by robin.office.elvis.ru (10.111.1.40) with Microsoft SMTP Server id 14.3.301.0; Tue, 27 Sep 2016 22:07:35 +0300 Message-ID: <4CD64EE0965C4CC7882942207906422F@chichi> From: Valery Smyslov To: Stephen Farrell , The IESG References: <147499618776.4465.11672584634820556976.idtracker@ietfa.amsl.com> In-Reply-To: <147499618776.4465.11672584634820556976.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 22:07:32 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, david.waltermire@nist.gov Subject: Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 19:09:21 -0000 Hi Stephen, > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > This is a nicely written document... thanks! Thank you! > - I vaguely recalled that puzzles and IPR rang a bell. Did > the WG consider [1]? If not, and if it helps, I'm fine with > making a 3rd party declaration on that and last call could be > done again. Or maybe there's a better way to handle it. Or > maybe the WG considered it and are happy enough already that > it's not relevant or about to expire or abandoned or > something. ("Not relevant" would puzzle me:-) > > [1] https://datatracker.ietf.org/ipr/417/ The WG didn't consider this particular IPR. > - section 3: "if certificates are involved" - you could note > here that involving certificates can introduce a network > based delay (OCSP, CRLs etc) that's a little different from > CPU consumption. (But it's a nit, and you do note a similar > issue in 4.7.) The network delay does not necessary take place (OCSP is optional, CRL may be cached), while CPU consumption is unavoidable. > - 4.2: "ratelimits should be done based on either the /48 or > /64" - would it be better to say "something between a /48 and > a /64" maybe? Don't some ISPs assign things in-between? This particular sentence was discussed by WG. I think that "either /48 or /64" was chosen for simplicity. > - 4.4: Did you consider making the "4 keys" requirement tied > to the PRF algorithm identifier? That would allow for a > future where e.g. 6 keys are needed for the same PRF, if that > were ever useful. (Without changing current implementations.) > I guess you'd need a separate IANA registry that'd initially > duplicate stuff in that case so maybe not worth doing. (And > could be done later.) Several puzzle solutions help reduce volatility of time needed to solve any given puzzle. I don't think it is related to particular PRF, since any "good" PRF must generate pseudorandom result and finding a key for that result would always involve a fortune for the Initiator. The fixed number of keys (4) is a compromise. We considered setting it to larger value, say 16 (and it would make correlation between puzzle difficulty and the time needed to solve it more predictable), but it would increase IKE message size in initial exchange. And it is a bad thing, since it increases the chances that the message exceeds MTU and is fragmented by IP, with all negative consequences. > - 7.1.1 - you don't clearly say if the cookie value here can > be a new one or should be the same as one previously used (if > one was previously used). That may just be my ignorance of > IPsec cookies though, but I wondered if there are any cases > where the initiator gets to work away on the puzzle ahead of > time if the same cookie is used for multiple interactions. > There's not much (or zero) of an improvement to the attack > here, though maybe the attacker could more easily offload > puzzle solving to someone else in that case? In IKEv2 the cookie is usually generated by applying hash function to Initiator's IP, SPI, nonce and some secret maintained by Responder. Since the cookie must be stateless for the Responder, it is not stored on the Responder (except for the secret, which is global and is changed periodically). So, if the Initiator uses the same IP, same SPIi and the same nonce, it will very likely receive the same cookie until the secret is changed. However, it won't much help an attacker. Once the puzzle is solved and the attacker successfully creates half-open SA on the Responder, it cannot use the same combination of IP and SPI to create another one, because all the initial messages with the same IP+SPI will be delivered to that half-open SA and discarded. The attacker can however gain some benefits if he/she waits some time until the half-open SA is expired on Responder and chooses the same SPI and nonce for the next connection request. He/she will receive the same puzzle if the Responder doesn't change value of secret yet. Note that RFC7296 recommends changing secret frequently if under attack (RFC7296, Section 2.6): The responder should change the value of frequently, especially if under attack. I think we can add some words to the draft that will recommend to generate cookie in such a manner, that the cookie is not repeated even if the same IP, SPI and nonce are used by Initiator. Thank you, Valery Smyslov. From nobody Tue Sep 27 12:22:03 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3499012B49E; Tue, 27 Sep 2016 12:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZMn7V_7msij; Tue, 27 Sep 2016 12:21:50 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9D012B333; Tue, 27 Sep 2016 12:21:49 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id l132so30736180wmf.1; Tue, 27 Sep 2016 12:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EdQs647tSS60y436ES155uug0NaaEL71xRO9AEZ7OA0=; b=si7bl4Z3RYPwyuxvMWLIKD4RTbvfJNPAiBj482n8tEzhjLqpiRWBpi9UWqJFpPfaV9 ZeRT/YF0VMIHf/VurJiS5HcUj0SSZt0FBYqg1RrB1f/uwONdp8hHR+TI551lj1inN+Rm mECqchobFRHY2xDCVegENkgPFZ+SatOVC1RRDlNbbHPMBTyPATTbrnHxGGEW+ZfxN+do ar/+/2SZbCDNZq99w0gsfwG7NRcgA7c8LGTHuf31t8n6HJJ/cS54rh6lxsE06KNfNrM1 RlPHjPg0RyxTteWuUKXaD+O+XsoBSxboLPSwHVkvihmzO/gRFlR1Lt6mZhbpJAT4mayY rf5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EdQs647tSS60y436ES155uug0NaaEL71xRO9AEZ7OA0=; b=dr5o96IcFVcWU4kZN1E2ORuAQqwgmAAczT4nWIcUp9vSRLk9qHKnogEp6JIQEmEkWj TIu69UT4PzAKYu/TL57FNa1bEWyD5BPvND5e6glFvJQpLgVtBn+0qXu8jAoG1tyNkzco xs132MIGKHBLVaOdRxUHobA9O19Nv7imIM5kBkR8xsswZWVx7NK6bu3kwqp8TlVfhTCl 2rYiyo0nIsXRgG84jOLfU5q3lrCqOolZfYwu15Qwxn0X7DXBrGEUxukn+L/hYn1BPNYH dTHhC+UQV6str3YTZxoEjYBxc+o+VUjZ5EIJBD1ELpvoX2R595I28saAeETdDVypg1d+ Ktrw== X-Gm-Message-State: AE9vXwMcHOB1wa/gefOCbn0VhpItiEbF8rE3Dbpm+wh0a7V88TbGY992FxWkbZ7HX00B+g== X-Received: by 10.194.190.37 with SMTP id gn5mr24289065wjc.168.1475004108136; Tue, 27 Sep 2016 12:21:48 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 123sm4658176wmj.5.2016.09.27.12.21.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 27 Sep 2016 12:21:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <147499618776.4465.11672584634820556976.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 22:21:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3583754A-964B-4BAF-85DC-126373EF8857@gmail.com> References: <147499618776.4465.11672584634820556976.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, The IESG , David Waltermire Subject: Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 19:21:52 -0000 On 27 Sep 2016, at 8:09 PM, Stephen Farrell = wrote: > This is a nicely written document... thanks! >=20 > - I vaguely recalled that puzzles and IPR rang a bell. Did > the WG consider [1]? If not, and if it helps, I'm fine with > making a 3rd party declaration on that and last call could be > done again. Or maybe there's a better way to handle it. Or > maybe the WG considered it and are happy enough already that > it's not relevant or about to expire or abandoned or > something. ("Not relevant" would puzzle me:-) >=20 > [1] https://datatracker.ietf.org/ipr/417/ We did not consider this one. We did consider a Sun/Oracle patent but = ultimately worked around this by replacing the type of puzzle. The = current puzzle is based on the proof-of-work algorithm used in Bitcoins.=20= Looking at the IPR statement you linked to, it does not seem relevant to = me, but IANAL. The proof-of-work scheme described in the patent ([2]) = involves setting a time limit for the client to complete the puzzle = solution. The puzzle in our draft has a set difficulty level, but no = time limit for the Initiator to solve it. [2] https://libpatent.com/patents/07197639 > - section 3: "if certificates are involved" - you could note > here that involving certificates can introduce a network > based delay (OCSP, CRLs etc) that's a little different from > CPU consumption. (But it's a nit, and you do note a similar > issue in 4.7.) True. But I think that for most devices used as IKE responders the = bottleneck is going to be the amount of CPU they can dedicate to = verifying signatures on certificates and CRLs/OCSP responses, not the = amount of memory they need to allocate while they=E2=80=99re waiting for = a response from whatever servers on the network. IOW if a certain device = is capable of verifying the signatures on certificate and CRLs for n = initiators per second and there is a total network delay of t to get all = the necessary CRLs or OCSP responses and a memory allocation of m for = every in-progress IKE Exchange, the same device will be able to allocate = much more memory than the m*n*t that is needed to support the n*t = concurrent exchanges. > - 4.2: "ratelimits should be done based on either the /48 or > /64" - would it be better to say "something between a /48 and > a /64" maybe? Don't some ISPs assign things in-between? They do. It even says so earlier in the same paragraph. But the = Responder does not know what the practices are at the Initiator=E2=80=99s = ISP. We know that prefixes longer than /64 are too granular and that = prefixes shorter than /48 are too coarse for marking a certain range of = addresses as attacking. I suppose the Responder could choose something = in between, but I don=E2=80=99t think there=E2=80=99s ever a good = justification for say /50 or /58. /48 and /64 seem to make the most = sense.=20 > - 4.4: Did you consider making the "4 keys" requirement tied > to the PRF algorithm identifier? That would allow for a > future where e.g. 6 keys are needed for the same PRF, if that > were ever useful. (Without changing current implementations.) > I guess you'd need a separate IANA registry that'd initially > duplicate stuff in that case so maybe not worth doing. (And > could be done later.) Since the level of the puzzle is settable by tweaking the required = number of zero-bits, the number of required answers plays no part in the = level of difficulty. Rather, it is used to smooth out the puzzle = difficulty. See my response to Mirja on this and also = https://mailarchive.ietf.org/arch/msg/ipsec/v7PFBEWeaT6ZQCjzCmIaxbRnZ8A > - 7.1.1 - you don't clearly say if the cookie value here can > be a new one or should be the same as one previously used (if > one was previously used). That may just be my ignorance of > IPsec cookies though, but I wondered if there are any cases > where the initiator gets to work away on the puzzle ahead of > time if the same cookie is used for multiple interactions. > There's not much (or zero) of an improvement to the attack > here, though maybe the attacker could more easily offload > puzzle solving to someone else in that case? >=20 I see that while I=E2=80=99m typing this Valery has also replied, so = I=E2=80=99ll leave this part to him, as he replied at length. Yoav From nobody Tue Sep 27 12:31:09 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A6912B4AC; Tue, 27 Sep 2016 12:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.617 X-Spam-Level: X-Spam-Status: No, score=-6.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkdhXpjDvjIn; Tue, 27 Sep 2016 12:30:58 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C38B12B4B1; Tue, 27 Sep 2016 12:30:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A832ABE49; Tue, 27 Sep 2016 20:30:54 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIwUmcnOMBjh; Tue, 27 Sep 2016 20:30:52 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 46269BE47; Tue, 27 Sep 2016 20:30:52 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1475004652; bh=5XQwhL267vb0tZWaGQ2Ec+lyIp28/4KSX4IQLs0BXcM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=EOeaGeXsn+7b1aPp7pPaCG5N0iPq8jDrwhG1ER3zRyXuHURQI/g7Rl965A9cQoRzn HZZlK52rKZABYE+qyNloH4s8Oc3zaBtYdOphR3skzXh+OtbW0xm/VdvRlWfEfC4T9v cC7w8M7qPFgl3IKzZUkYUpOLVZ6yXvQIH/7ugmYM= To: Yoav Nir References: <147499618776.4465.11672584634820556976.idtracker@ietfa.amsl.com> <3583754A-964B-4BAF-85DC-126373EF8857@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 27 Sep 2016 20:30:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <3583754A-964B-4BAF-85DC-126373EF8857@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060706070609060409010406" Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, The IESG , David Waltermire Subject: Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 19:31:00 -0000 This is a cryptographically signed message in MIME format. --------------ms060706070609060409010406 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 27/09/16 20:21, Yoav Nir wrote: > Looking at the IPR statement you linked to, it does not seem relevant > to me, but IANAL. The proof-of-work scheme described in the patent > ([2]) involves setting a time limit for the client to complete the > puzzle solution. The puzzle in our draft has a set difficulty level, > but no time limit for the Initiator to solve it. FWIW, that sounds reasonable to me. But I've given up pondering what lawyers think about patents so folks can make up their own minds;-) S. --------------ms060706070609060409010406 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5Mjcx OTMwNTJaMC8GCSqGSIb3DQEJBDEiBCDD0cHMVqlUTo2n1NhlckyOHx5182jXEFfILTfC2cIj ODBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCUQ+B6LoasHlYdBZE8yzmppXxEOqIfmMAKnjpKkR1ueeGRlnB4H6V/ qnU9zm3YMyOKaGYc4hkhr9DEwLYhj881p9DtN+tyKyd1Q+46d0Hd9L1fqLacDjJITZEts/T8 D38rCLCRowQIqhpIgvdIA25mLrqk11pXIIT41ncdZ0ttvnqu8Lpwcw681oGboFi6GAadMxzo 0+L4TEbK3wNy0/IkNgggeyY+j9EwwugeZtF7RVeCpjermmlB8cR/hVwy+gJcRX2NPd4+2tjW u9XyQYaH+9qTSPjVwIxlYCPxn/sg6DZwUtbVVspuRnNxLiwsUY4EqntxB1A4Nt9u9ykqaP5L AAAAAAAA --------------ms060706070609060409010406-- From nobody Tue Sep 27 12:32:09 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C57712B4AC; Tue, 27 Sep 2016 12:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.617 X-Spam-Level: X-Spam-Status: No, score=-6.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFNTbUmkFdnt; Tue, 27 Sep 2016 12:32:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7475812B4B4; Tue, 27 Sep 2016 12:32:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AA357BE49; Tue, 27 Sep 2016 20:31:59 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWAY2NkSgOv0; Tue, 27 Sep 2016 20:31:58 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E2EE9BE47; Tue, 27 Sep 2016 20:31:57 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1475004718; bh=zLiju+KPSJ7yba0U2zf3BrglNUrEsFO66zYwRcNGmLw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=MZRh378QocDKU/gPg8BdGKgcXhiaJ4u8kFRVRwil7iJ9PCKKGsAOFS0xVJpYLBPTi NzwkfU3M30E0yZYS0Omky7ta3QLIX3Tqp/bkeR5vOhPBYrlbvXbgf94UiLNSuCwGDc cR2j9IIGZAjzmMShLF99iZCxc73sX4vGi0IJwsWE= To: Valery Smyslov , The IESG References: <147499618776.4465.11672584634820556976.idtracker@ietfa.amsl.com> <4CD64EE0965C4CC7882942207906422F@chichi> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 27 Sep 2016 20:31:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <4CD64EE0965C4CC7882942207906422F@chichi> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080702030607080201080005" Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, david.waltermire@nist.gov Subject: Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 19:32:03 -0000 This is a cryptographically signed message in MIME format. --------------ms080702030607080201080005 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 27/09/16 20:07, Valery Smyslov wrote: >=20 > The attacker can however gain some benefits if he/she waits some time > until the half-open SA is expired on Responder and chooses the same SPI= > and nonce for the next connection request. He/she will receive the same= > puzzle > if the Responder doesn't change value of secret yet. Note that RFC7296 > recommends > changing secret frequently if under attack (RFC7296, Section 2.6): >=20 > The responder should change the value of frequently, especia= lly > if under attack. >=20 > I think we can add some words to the draft that will recommend > to generate cookie in such a manner, that the cookie is not repeated > even if the same IP, SPI and nonce are used by Initiator. Good one. Yeah I think it'd be fine to add that. All the rest of your and Yoav's responses are good too. Thanks, S. --------------ms080702030607080201080005 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5Mjcx OTMxNThaMC8GCSqGSIb3DQEJBDEiBCDFHr7VFjLR1St30aLNnDCVWV7P/U8i0n8DbmKc0Vr8 IDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBQUyJkpsrXKKkfPRLZzlwYTn/1HwakSqoZWjqOs5Eoz33rnDDx0F9a piYJrpoysjArm8v7PMLmev2WeYgJEso72WBS7oY2+/D7Mkw628hexcJjzsRKuXgGrCryFYXk PcNxM2/iswJsp+MpKJZl0lWTj2ETumt0H4X/af7hSCuRZ58V9XeVVob6Sk0ZPwOg7YGm9m1d k8o1ILJUMwedqH+Efi1W4pG2WN/KkwtTJfcBK3vcYw3t2LqfSgVGGBwYbwst1vlPubjuDmGc vX2JT5CxHRytWOVnFAVawWri21CnjW1gRRKrc9EEEHx1p7U707Fr9ZpdjlSMDMwrSbS5TOu2 AAAAAAAA --------------ms080702030607080201080005-- From nobody Tue Sep 27 15:30:09 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0990B12B3FD; Tue, 27 Sep 2016 15:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=B92Lry09; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=npfJxUTk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfCoIt6LAwxe; Tue, 27 Sep 2016 15:29:57 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C510C12B49A; Tue, 27 Sep 2016 15:29:49 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 24EBC205FD; Tue, 27 Sep 2016 18:29:49 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 27 Sep 2016 18:29:49 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=ix4mcZtaNVAztfZZbvk7ct8UwwQ=; b=B92Lry 09K9eL244HqVR8zWIhqQgNkvjs2VgVNG4/kYyysM3Aa5wNpu7R1G/73Sv5Moc4E7 c2JBfLMBYytalIXnw9QOESrMQNwcFS+Vm9B66LziG7356VYoq2Cq3UKqswqnuPVd sKBlTv5nyKX/ecC17Sgxy4g6H4UvI3sV2z1ZA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ix4mcZtaNVAztfZ Zbvk7ct8UwwQ=; b=npfJxUTkFdDjRYjNGQgVmSixdAAxoJ8hKYtDR8BZcKcgWQG cjzAnTNZd+lo+0UCJzb2PM8Dj48bHIjzUtBHdBt7ibcLYgK4OWjUBFx9Py3xcXf5 /FcHcYwAkmnICvLkNrYxqULliNU8zyJyA7B3dJIeTUqUFYj5iF6KRWuiwaR4= X-Sasl-enc: m+C+ZwLWt2DNjKzmC8+MPoQgP8YPdprgXVHMCzteIT6n 1475015388 Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by mail.messagingengine.com (Postfix) with ESMTPA id BD7B5F2988; Tue, 27 Sep 2016 18:29:48 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (13G36) In-Reply-To: Date: Tue, 27 Sep 2016 23:43:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147497133669.20752.15148121845053327482.idtracker@ietfa.amsl.com> To: Valery Smyslov Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, The IESG , David Waltermire Subject: Re: [IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 22:30:09 -0000 Hi Valery, > On 27 Sep 2016, at 12:42, Valery Smyslov wrote: >=20 > Hi Alexey, >=20 > payload type for the Puzzle Solution Payload is specified in the last sent= ence > of Section 8.2: >=20 > The payload type for the Puzzle Solution payload is . >=20 > It is not included in the diagram in this section since the "Next Payload"= field in generic payload header contains the type of the following payload,= not the type of payload the diagram depicts. Ok, this is what I missed. I just wanted to make sure that whoever parses a r= esponse can figure out where a puzzle solution starts and whether it is pres= ent. Thank you, Alexey From nobody Thu Sep 29 02:58:55 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EF812B362; Thu, 29 Sep 2016 02:58:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147514313319.18489.2408704727514347470.idtracker@ietfa.amsl.com> Date: Thu, 29 Sep 2016 02:58:53 -0700 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, kivinen@iki.fi Subject: [IPsec] ipsecme - New Meeting Session Request for IETF 97 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 09:58:53 -0000 A new meeting session request has just been submitted by Tero Kivinen, a Chair of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 30 Conflicts to Avoid: First Priority: cfrg saag tls curdle tcpinc mile sacm Second Priority: 6tisch lwig ace httpauth Third Priority: uta 6lo dane tcpm netmod Special Requests: --------------------------------------------------------- From nobody Thu Sep 29 04:05:24 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F22F12B4DC for ; Thu, 29 Sep 2016 04:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQyhdFVSPX1h for ; Thu, 29 Sep 2016 04:05:19 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EB6912B4CB for ; Thu, 29 Sep 2016 04:05:17 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u8TB5Cjo024391 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Sep 2016 14:05:12 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u8TB5C3g012341; Thu, 29 Sep 2016 14:05:12 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22508.62824.314814.780741@fireball.acr.fi> Date: Thu, 29 Sep 2016 14:05:12 +0300 From: Tero Kivinen To: Wang Jian In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 5 min Archived-At: Cc: IPsecME Subject: [IPsec] Flexible multi-factor authentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 11:05:22 -0000 Wang Jian writes: > The MFA we finally implemented is like > > 1. Users first authenticate themselves with username & password I.e., some suitable EAP method. > 2. according to the user's security group, another OTP authentication > step is needed or not. For users that OTP is needed, OTP > authentication is prompted or skipped if (the device,the user) tuple > was authenticated recently (i.e. 24 hours) And here again another suitable EAP method. > * We could not get unique device id, so IP address and username are > used as the tuple. However we prefer to a generated permanent device > id by vpn client, the device's manufacturer-assigned id (or derived > hash if privacy is a concern), or time-limited http-cookie-like id > generated and returned by authenticator. In normal case you use different IDs in different authentication methods. I.e., you do device authentication first using Device ID as your IDi, for that you can use certificates or something. Then on the second phase you do user authentication using user name as IDi and users password for EAP etc. All this can be done using RFC4739 Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol, which is there just for this reason, i.e. to provide multiple authentication methods for one connection. > Current IKEv2 doesn't provide an EAP authentication method to support > such flexible MFA use case. And in the new charter, there is no goal > of the kind. IKEv2 protocol with RFC4739 can support such methods, but implementations might not implement them, so you need to find implementation that actually support RFC4739 and uses it to do multiple authentication methods in a way you want to use them. > IMHO, flexible MFA is most important for large scale enterprise > deployment. Please add it as a goal. This is exactly the reason why RFC4739 was done in 2006... -- kivinen@iki.fi From nobody Thu Sep 29 07:35:54 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0FE12B183 for ; Thu, 29 Sep 2016 07:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkFQTFmwBzAG for ; Thu, 29 Sep 2016 07:35:50 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D5412B176 for ; Thu, 29 Sep 2016 07:35:50 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id 192so76433522vkl.2 for ; Thu, 29 Sep 2016 07:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=swWlRdF3jcRcRW2REKCzDwTqic0arFMDizjQi946AjU=; b=SQjijAPSoEzCbeeUJoL6MBDF+MEdB48KrR8CKnz5pBSjEqRSuhWnjw+7FYdxUBIiby f21vedt91JbDYsxo362OQLrhKIDwsSiXZy8HQ/U3getviVM6wUAlEbWnFfAxqst6WBZC adwz2eKSvDQ3u7tErjEpIeyurL2LSW31iJmgwrZU27h5DNEpddp8daAm9E22c90AzNcW MJQduvDwDiSCuNfPoKwLyVPPfIHWZXz6ddBR4e7yN3YgiXHJSnrubGhYjgdpgbs2GvaV m2Ydi+KTXpvz8QLNipEWn9fBM9Vl4M6oVlfpKYrXy7O7rFed5uixgAQbxU1o8jSHvIdv CPOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=swWlRdF3jcRcRW2REKCzDwTqic0arFMDizjQi946AjU=; b=KYeAcopjq1ZC1mJdliTPoCjpwExNkxzsW2Klhis9qUmpqQURZYqx0R7HuuW/pkyd4a Usd23sK4hODY68qS//bC+tEpohewXjUYTcLkvT2R2XPcypYaeUfWbCSpXrtiQOdMlK9V v29mL7rXuCeonhjE948kymp2jc4M0R5C4nALRCnLrISgDyDAnpmLPckB6WvHMXiDrdZe O1MfxeRHPUG3TNZyqMN+tFcTrdRIPAwCpSaMxcpdf1I0zhTVCskOd66RfF1oGIUPAfp8 qlxZQu8RViSLmWcLhRV2l13Di1/8LGw4OYTVgnzllmFc3PDM1mZrjXNbmjvkkhah4eFq R7cw== X-Gm-Message-State: AA6/9RngVc6LRFqx5IiB7crBN2/k+RJrvLscDZVxGMEttWd15w8Bp4ocHfGcGal4b1KYGn+Pm7gEguKa37T9Pg== X-Received: by 10.31.168.145 with SMTP id r139mr1296939vke.124.1475159749626; Thu, 29 Sep 2016 07:35:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.8 with HTTP; Thu, 29 Sep 2016 07:35:49 -0700 (PDT) From: Kathleen Moriarty Date: Thu, 29 Sep 2016 10:35:49 -0400 Message-ID: To: "ipsec@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [IPsec] DDoS puzzles X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 14:35:52 -0000 Hello, This draft has been approved for publication and I will push it forward once an update includes corrections from any discusses and comments that are outstanding. -- Best regards, Kathleen From nobody Thu Sep 29 07:54:39 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC1012B14B for ; Thu, 29 Sep 2016 07:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnxnYWpMOyfu for ; Thu, 29 Sep 2016 07:54:35 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0094.outbound.protection.outlook.com [23.103.201.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B752612B0FC for ; Thu, 29 Sep 2016 07:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JGXKEj0waAR0c3E08k6rR4r2yQUe/zzIXkTlOBk0mVg=; b=yFH7YKtjUR1oONdi3mjSzz6jkRVOH+cmJxCIqTNKM7KB/TShgfxCObNTd9n2NVmLIXyDABaeQyevl+dTHvzcxaU+fnGuHQdLHwMjeT59fiUeaWAatml7vqVVMrjQC9CiLjBp6+esi3dRttgijS6sdIlz+6H1GaKc5o8kSUNhzBM= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1438.namprd09.prod.outlook.com (10.173.50.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Thu, 29 Sep 2016 14:54:34 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0639.015; Thu, 29 Sep 2016 14:54:34 +0000 From: "Waltermire, David A. (Fed)" To: Kathleen Moriarty , "ipsec@ietf.org" Thread-Topic: [IPsec] DDoS puzzles Thread-Index: AQHSGl7OBTAoqDLi2keNeSJAHIwCsKCQjWsw Date: Thu, 29 Sep 2016 14:54:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [132.163.220.140] x-ms-office365-filtering-correlation-id: da92e7b0-95a7-4b9a-3aa5-08d3e87886c7 x-microsoft-exchange-diagnostics: 1; MWHPR09MB1438; 7:mWdPGCsfpdj0vX2QvPzS1Kap5AeDZ4TrUlDmpJKkvdJsUkTfHmnTkSWfE5tsFd8wXoFdp3rhFXZSKId2NsGYvZo4Uy/0XfUnFRD36Z+9ffoPQVfB0ws8MJdEdBGq9/u8KnOYGNDNQGOGrJVB4/SdjCMAStrX/PAd90VlbOwIMrKOwRHl8nHIG/DfMFQiZAw8qY31SiH1YXRzT82Wl//UfkaJ1kfe1tSXuPBWOaT30mIifwUO4dhq+BDjIVci8Ie2IyKmwH2Ee0y+dLgjHpc3S8ngiJDKDesvO63ug+J35V69ZziWbu0HWaedmgVrViFr0y96JfUGRCsE4CHUuQYUGw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR09MB1438; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:MWHPR09MB1438; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1438; x-forefront-prvs: 00808B16F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(199003)(13464003)(2950100002)(7696004)(10400500002)(586003)(97736004)(189998001)(5001770100001)(107886002)(7736002)(305945005)(74316002)(81156014)(81166006)(8676002)(5002640100001)(66066001)(7846002)(86362001)(122556002)(3846002)(101416001)(102836003)(77096005)(11100500001)(15975445007)(2900100001)(3280700002)(50986999)(3660700001)(76176999)(68736007)(2501003)(54356999)(105586002)(99286002)(76576001)(33656002)(9686002)(87936001)(19580395003)(19580405001)(5660300001)(6116002)(92566002)(106116001)(106356001)(8936002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1438; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2016 14:54:34.2053 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1438 Archived-At: Subject: Re: [IPsec] DDoS puzzles X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 14:54:38 -0000 Thank you Kathleen. And thanks to the authors and reviewers that have worke= d so hard on this draft. Regards, Dave > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Kathleen Moriart= y > Sent: Thursday, September 29, 2016 10:36 AM > To: ipsec@ietf.org > Subject: [IPsec] DDoS puzzles >=20 > Hello, >=20 > This draft has been approved for publication and I will push it forward o= nce > an update includes corrections from any discusses and comments that are > outstanding. >=20 > -- >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Sep 29 11:06:21 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA9012B1BD for ; Thu, 29 Sep 2016 11:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7awK4Ny_dezy for ; Thu, 29 Sep 2016 11:06:18 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798BA12B225 for ; Thu, 29 Sep 2016 11:06:17 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id 192so82340046vkl.2 for ; Thu, 29 Sep 2016 11:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i6A+v3NnN9NuADWv/r2jdshmuhrfunPJND9ZLYtYAdg=; b=PdCOAV3bxW/F3TB3enACVjim3jh/v++YGYFB7whkpNwZbaGhC+m3Birkvg23/spTS0 /lnyLvJ2fQXUU2O7z3V8mwxI67kZGZssdylS5I8Axbh4A9ZotoRxRioSZEU60NWug/oy FPCTHJrZgm68Bjd2Xw7vYF00g4/3GYCOxjmtfykFFTuemHpV6/9cTrADZNqwIpU+y3iu o5tJhuJH3Ccc1LrFlbImMII4tb//0Myva3Dta2/6bdxST7B33O4IncS/ZbuehOMuwPh7 yt2jv91P+ArBpzqJsjWC/WwgxowFj0qobvPUOgrjSYSYdX8iPPMI0Fe1v6F4qcnSYUbE hZfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i6A+v3NnN9NuADWv/r2jdshmuhrfunPJND9ZLYtYAdg=; b=SxFD9FBF63yF6GHAIIxVcONiouK5/PDznywU5Arvh3QwwV+X+d3hf0y9d5iN7+6L40 Z9Ho7uvrh+jrRyiCKVGvDh5xJhoSjvUvrPqRBvrwIEDdyfqD7CT0f84PQQ4nxM5EPqHr AIUto2KDvcDLd2wc9wTDqM2t2t59aoAEoWpTQ547piKsEvNvF9Il6We5XlkZwE8CihOz HEKiPdtm30jUwLNaADloMo1yk8WhPInG2nzf9l+RokKA8HfBhG4pZ1bsdubqraQIiXSN QvArOE8eVBEyxUQ30D6hhH/L+TRTfZFturwLq+4v1ZnlQcIoyhvYwPw6+mT7A8ge9DnP T6Ug== X-Gm-Message-State: AA6/9RlBV+dt5x5mp/4oaSY7I+EDDCxMBBX1MGaGLTPkEFSWNBc8mNWrk9X7yHc/+s+q8OHFjdWXuIa+wA8c3g== X-Received: by 10.31.242.206 with SMTP id q197mr2178437vkh.46.1475172376483; Thu, 29 Sep 2016 11:06:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.97.71 with HTTP; Thu, 29 Sep 2016 11:06:15 -0700 (PDT) In-Reply-To: <22508.62824.314814.780741@fireball.acr.fi> References: <22508.62824.314814.780741@fireball.acr.fi> From: Wang Jian Date: Fri, 30 Sep 2016 02:06:15 +0800 Message-ID: To: Tero Kivinen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPsecME Subject: Re: [IPsec] Flexible multi-factor authentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 18:06:20 -0000 2016-09-29 19:05 GMT+08:00 Tero Kivinen : > Wang Jian writes: >> The MFA we finally implemented is like >> >> 1. Users first authenticate themselves with username & password > > I.e., some suitable EAP method. > >> 2. according to the user's security group, another OTP authentication >> step is needed or not. For users that OTP is needed, OTP >> authentication is prompted or skipped if (the device,the user) tuple >> was authenticated recently (i.e. 24 hours) > > And here again another suitable EAP method. > >> * We could not get unique device id, so IP address and username are >> used as the tuple. However we prefer to a generated permanent device >> id by vpn client, the device's manufacturer-assigned id (or derived >> hash if privacy is a concern), or time-limited http-cookie-like id >> generated and returned by authenticator. > > In normal case you use different IDs in different authentication > methods. I.e., you do device authentication first using Device ID as > your IDi, for that you can use certificates or something. > > Then on the second phase you do user authentication using user name as > IDi and users password for EAP etc. > > All this can be done using RFC4739 Multiple Authentication Exchanges > in the Internet Key Exchange (IKEv2) Protocol, which is there just for > this reason, i.e. to provide multiple authentication methods for one > connection. > >> Current IKEv2 doesn't provide an EAP authentication method to support >> such flexible MFA use case. And in the new charter, there is no goal >> of the kind. > > IKEv2 protocol with RFC4739 can support such methods, but > implementations might not implement them, so you need to find > implementation that actually support RFC4739 and uses it to do > multiple authentication methods in a way you want to use them. > >> IMHO, flexible MFA is most important for large scale enterprise >> deployment. Please add it as a goal. > > This is exactly the reason why RFC4739 was done in 2006... Thanks for pointing me back at RFC4739. I came to know this RFC4739 when I evaluated strongswan. I can't remember exactly why I put aside RFC4739. I re-read RFC4739 to collect my memory. "" It is assumed that both peers know what credentials they want to present; there is no negotiation about, for instance, what type of authentication is to be done. As in IKEv2, EAP-based authentication is always requested by the initiator (by omitting the AUTH payload). "" The multiple authentication exchanges here are not flexible, especially for mobile devices and BYOD scenario. A flexible MFA mechanism should be server driven. The responder or AAA backend can dictate what methods are mandatory, what methods are optional, according to the knowledge the server collects. For example: username and password is required, one of certificate, OTP or fingerprint is required. Back to my company's setup, that is 1. Server mandates username and password authentication 2. If server has knowledge that this device of this user is authenticated successful recently, server will skip the OTP authentication step, otherwise, OTP authentication is required if user is in a high priviledge user group RFC4739 doesn't provide this flexibility. EAP-TTLS tunnelled authentications are more attractive than RFC4739. Regards, Wang Jian