From nobody Fri Oct 3 03:26:31 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC181A0263 for ; Fri, 3 Oct 2014 03:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZThSxcCALP5 for ; Fri, 3 Oct 2014 03:26:26 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EDFC1A0243 for ; Fri, 3 Oct 2014 03:26:25 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s93AQMhP020684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 3 Oct 2014 13:26:22 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s93AQL2T004754; Fri, 3 Oct 2014 13:26:21 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21550.31181.696500.936115@fireball.kivinen.iki.fi> Date: Fri, 3 Oct 2014 13:26:21 +0300 From: Tero Kivinen To: ipsec@ietf.org In-Reply-To: References: <201409300906.s8U96g22025789@smtp1.lax.icann.org> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 9 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/jp4mmK5icjfkq627YEjVaQwkmhU Subject: [IPsec] [IANA #785032] General Request for Assignment (ikev2-parameters) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 10:26:30 -0000 Got following request form IANA, and approved it. This is just for information in case someone is interested. Amanda Baber via RT writes: > We have another request for an IKEv2 Configuration Payload Attribute > Type. If this is OK, how should we fill in the "Multi-Valued" and > "Length" columns? > === > > Contact Name: > Frederic Firmin > > Contact Email: > frederic.firmin@etsi.org > > Type of Assignment: > IKEv2 configuration attribute > > Registry: > IKEv2 Configuration Payload Attribute Types > > Description: > see 24.302 F3.3. When FTT_KAT configuration attribute is included in > the CFG_REQUEST configuration payload of IKEv2 security association, > packets of which are transported via FTT, the Keep-alive time field > indicates preferred maximum time in seconds between two envelopes > (any of those described in subclause F.3.2) sent via FTT. When > FTT_KAT configuration attribute is included in the CFG_REPLY > configuration payload of IKEv2 security association, packets of > which are transported via FTT, the Keep-alive time field indicates > actual maximum time in seconds between two envelopes (any of those > described in subclause F.3.2 of 24.302) sent via FTT. > > Additional Info: > 24.302 12.6.0 available at http://www.3gpp.org/DynaReport/24302.htm This parameter is related to the EPC (evolved packet core), where they use IKEv2 and ESP to connect the UE (user equipment, i.e. the phone) to the ePDG (evolved packet data gateway, i.e. their IPsec gateway) over non-3gpp network (i.e. wlan etc). They have feature called FTT (firewall traversal tunnel), where they try to get connectivity even when the non-3gpp networks is very restrictive, i.e. firewalls block IKEv2 and ESP traffic, but https goes through. In that case they tunnel IKEv2 and ESP through TLS tunnel made from the UE to the ePDG (possibly through proxy). For this tunnel they want to use keepalives, but the normal IKEv2 NAT-T keepalives are not usable here as this is over TLS over TCP, not over UDP, and the keepalives needed in those environments are in the order of 10 minutes, not 10 seconds... This configuration parameter is used to configure the keepalive interval for the tunnel. They have their own mechanism to wrap the IKEv2, ESP, and the keepalive packets sent over the TLS tunnel. This looks ugly, and the usability might not be the best when you are running IP over TCP, but if the environment is such that, this is only connectivity you get (hotel etc), it is best you can do... That is at least what I understood from their 24.302 specification with quick check. -- kivinen@iki.fi From nobody Sun Oct 5 03:25:58 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E901A1A98 for ; Sun, 5 Oct 2014 03:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPOnKj6kYgEW for ; Sun, 5 Oct 2014 03:25:55 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA501A1A93 for ; Sun, 5 Oct 2014 03:25:55 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so3039908lab.33 for ; Sun, 05 Oct 2014 03:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=DAQ5NdFVOsYuCfFHGey1GyaaOswHHiifveOyF4sMIFo=; b=JCx9MMQDvOQDZzRQKJ1mT8igTAi/Es67eO6/X9wVxkfGtEe8nKmN47fiZUPKHqXDA4 3SljZdHTVCgihEQ0bKLmImgIYc6YQhWacJqhtHR5eQtqI1ZmyNWtkkm0glBFUmxMwzuj gSOlVcy5JWiaJCalcrgDdNS0mvorlH8/aWKIUe6Z3UnKKC13bPVuAcfnWwMzzpsmiN26 iElHIBmNH/xvnCBEsu7T6+38Z8R1HFMJ5A11zMWxpwol4BJyi1/geToU4MvFmd3pEE4y 3bsYLyJKW92eDh38263TSdG7j5Lq7c8aVAN58zdPhAOXifyy+ApDQyaRzmBFu273DIec DqbQ== X-Received: by 10.112.171.229 with SMTP id ax5mr16474626lbc.25.1412504753419; Sun, 05 Oct 2014 03:25:53 -0700 (PDT) Received: from [172.24.251.145] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id tl8sm4579979lbb.47.2014.10.05.03.25.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 Oct 2014 03:25:52 -0700 (PDT) From: Yoav Nir Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9612D2B2-7DFE-49F5-8593-3750B781956B@gmail.com> Date: Sun, 5 Oct 2014 13:25:49 +0300 To: ipsec Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/9Ngrucpf9s9bD7gmH5Z7zKve788 Subject: [IPsec] A strategy against DoS/DDoS for IKE responders X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 10:25:57 -0000 Hi Here are some thoughts about DoS and DDoS protection for an IKE daemon. = I think this should be discussed before submitting any drafts, because = the acceptance thread reflected that the problem we want to solve is DoS = and DDoS, not just the lack of a puzzle mechanism. If we break down what a responder has to do during an initial exchange, = there are four stages: 1. When the Initial request arrives, the responder: - generates or re-uses a D-H private part. - generates a responder SPI - stores the private part and peer public part in a half-open SA = database. 2. When the Authentication request arrives, the responder: - derives the keys from the half-open SA ([1]). - decrypts the request. =20 3. If the Authentication request decrypts properly: - validates the certificate chain (if present) in the auth request Yes, there's a stage 4 where the responder actually derives keys, but = when talking about (D)DoS, we never get to this stage. Stage #1 is pretty light on CPU power, but requires some storage, and = it's very light for the initiator as well. Stage #2 includes private-key = operations, so it's much heavier CPU-wise. Stage #3 includes a public = key operation, and possibly many of them. To attack such a server, an attacker can attempt to either exhaust = memory or to exhaust CPU. Without any protection, the best avenue is to = send multiple faked Initial requests, and exhaust memory. This should be = easy because those Initial requests are cheap. There are obvious ways for the responder to protect itself even without = changes to the protocol. It can reduce the time that an entry remains in = the half-open SA database, and it can limit the amount of concurrent = half-open SAs from a particular address or prefix. The attacker can = overcome this by using spoofed source addresses. The stateless cookie mechanism (that is already in the RFC) prevents an = attack with spoofed source addresses. This doesn't solve the issue, but = it makes the address or prefix limiting work. Puzzles do the same thing = only more of it. They make it harder for an attacker to reach the goal = of getting a half-open SA. They don't have to be so hard that an = attacker can't afford to solve them - it's enough that they increase the = cost of a half-open SAs for the attacker.=20 Reducing the amount of time an abandoned half-open SA is kept attacks = the issue from the other side. It reduces the value the attacker gets = from managing to create a half-open SA. So if a half-open SA takes 1 KB = and it's kept for 1 minute and the capacity is 60,000 half-open SAs, an = attacker would need to create 1,000 half-open SAs per second. Reduce the = retention time to 3 seconds, and the attacker needs to create 20,000 = half-open SAs per second. Make each of those more expensive, and you're = likely to thwart an exhaustion attack against responder memory. At this point, I'm guessing that this is no longer the most efficient = DoS attack. The attacker has two ways to do better: 1. Go back to spoofed addresses and try to overwhelm the CPU that deals = with generating cookies, or 2. Take the attack to the next level by also sending an Authentication = request. =20 I don't think the first thing is something we can deal with at the IKE = leve. It's probably better left to IPS technology. Sending an Authentication request is surprisingly cheap. It requires a = proper IKE header with the correct IKE SPIs, and it requires a single = encrypted payload. The content of the payload might as well be junk. The = responder has to perform the relatively expensive key derivation, only = to find that the Authentication request does not decrypt. Depending on = the responder implementation, this can be repeated with the same = half-open SA (if the responder does not delete the half-open SA = following an unsuccessful decryption). For extra credit, the attacker = can send the Authentication request just before the entry expires. Here too, the number of half-open SAs that the attacker can achieve is = crucial, because each one of them allows the attacker to waste some CPU = time. So making it hard to make many half-open SAs is important.=20 A strategy against DDoS has to rely on at least 4 components: 1. Hardening the half-open SA database by reducing retention time. 2. Hardening the half-open SA database by rate-limiting single = IPs/prefixes 3. Guidance on what to do when an Authentication request fails to = decrypt. 4. Increasing cost of half-open SA up to what is tolerable for = legitimate clients 5. Other things? =20 Puzzles have their place as part of #4. I think a WG document should = cover all. Yoav [1] this could be done in part #1, but that makes the DoS issue worse.= From nobody Sun Oct 5 12:37:28 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211981A1AF3 for ; Sun, 5 Oct 2014 12:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVqBgz6GC5kM for ; Sun, 5 Oct 2014 12:37:25 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 242851A1AF2 for ; Sun, 5 Oct 2014 12:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11463; q=dns/txt; s=iport; t=1412537845; x=1413747445; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Ayob/YlRUPyzx2gdCukS4oJ+W6lt89B3bQhrhw6ys6w=; b=OeClAP08dN0pwPwL2cIJnuS2P3u4lyL0r5UXKJ4pGrgQM7Vo21Nfk8RQ iyZ83Gc+x/DrtMkeLwTiQt6dokei02q6ll0Hu4nEtBSDCdLSXQ/6gZ8/a uOMwjM9nl5vcQdhpVELrniSpr8A3MgG9QhvCX2g1WKXvPudmcyTJA/tEq A=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAP2cMVStJA2D/2dsb2JhbABWCIJrI1NYBMwACodNAn8WAXuEBAEBAwEBAQFrBgoLAgEIDjgCHwYLJQIEARIOiBwDCQgBDLdpDYcYARMEgmGHaINLgVoBCAUuIoRLBZF0gguBTIVighGPL4ZRgXIYgVlsgQcBHgYcgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,660,1406592000"; d="p7s'?scan'208";a="360918132" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP; 05 Oct 2014 19:37:24 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s95JbOxD007562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 5 Oct 2014 19:37:24 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Sun, 5 Oct 2014 14:37:23 -0500 From: "Graham Bartlett (grbartle)" To: Yoav Nir , ipsec Thread-Topic: [IPsec] A strategy against DoS/DDoS for IKE responders Thread-Index: AQHP4IbF+Xf2zTD2ikCTmGddD9T/C5wiSxeA Date: Sun, 5 Oct 2014 19:37:22 +0000 Message-ID: References: <9612D2B2-7DFE-49F5-8593-3750B781956B@gmail.com> In-Reply-To: <9612D2B2-7DFE-49F5-8593-3750B781956B@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.55.146.100] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3495386241_25648324" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/dWRdsop1rRvwt0_N07Si7whVoHw Subject: Re: [IPsec] A strategy against DoS/DDoS for IKE responders X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 19:37:27 -0000 --B_3495386241_25648324 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Yoav This is a subject I've spent way too much time thinking about and is close to my heart. :-) I'm actually surprised a Bot hasn't been used to take down a VPN service using the Auth attack that you describe, or not one that I've heard of. I'd like to add, for 1, if 6989 is employed then I was under the impression this could become a serious issue as these check can be resource intensive, also if a unique DH exchange per session this could considerable increase the workload. Great summary btw, I've included some comments inline GB> cheers On 05/10/2014 11:25, "Yoav Nir" wrote: >Hi > >Here are some thoughts about DoS and DDoS protection for an IKE daemon. I >think this should be discussed before submitting any drafts, because the >acceptance thread reflected that the problem we want to solve is DoS and >DDoS, not just the lack of a puzzle mechanism. > >If we break down what a responder has to do during an initial exchange, >there are four stages: > >1. When the Initial request arrives, the responder: > - generates or re-uses a D-H private part. > - generates a responder SPI > - stores the private part and peer public part in a half-open SA >database. > >2. When the Authentication request arrives, the responder: > - derives the keys from the half-open SA ([1]). > - decrypts the request. > >3. If the Authentication request decrypts properly: > - validates the certificate chain (if present) in the auth request > >Yes, there's a stage 4 where the responder actually derives keys, but >when talking about (D)DoS, we never get to this stage. > >Stage #1 is pretty light on CPU power, but requires some storage, and >it's very light for the initiator as well. Stage #2 includes private-key >operations, so it's much heavier CPU-wise. Stage #3 includes a public key >operation, and possibly many of them. > >To attack such a server, an attacker can attempt to either exhaust memory >or to exhaust CPU. Without any protection, the best avenue is to send >multiple faked Initial requests, and exhaust memory. This should be easy >because those Initial requests are cheap. > >There are obvious ways for the responder to protect itself even without >changes to the protocol. It can reduce the time that an entry remains in >the half-open SA database, and it can limit the amount of concurrent >half-open SAs from a particular address or prefix. The attacker can >overcome this by using spoofed source addresses. > >The stateless cookie mechanism (that is already in the RFC) prevents an >attack with spoofed source addresses. This doesn't solve the issue, but >it makes the address or prefix limiting work. Puzzles do the same thing >only more of it. They make it harder for an attacker to reach the goal of >getting a half-open SA. They don't have to be so hard that an attacker >can't afford to solve them - it's enough that they increase the cost of a >half-open SAs for the attacker. > >Reducing the amount of time an abandoned half-open SA is kept attacks the >issue from the other side. It reduces the value the attacker gets from >managing to create a half-open SA. So if a half-open SA takes 1 KB and >it's kept for 1 minute and the capacity is 60,000 half-open SAs, an >attacker would need to create 1,000 half-open SAs per second. Reduce the >retention time to 3 seconds, and the attacker needs to create 20,000 >half-open SAs per second. Make each of those more expensive, and you're >likely to thwart an exhaustion attack against responder memory. > >At this point, I'm guessing that this is no longer the most efficient DoS >attack. The attacker has two ways to do better: > 1. Go back to spoofed addresses and try to overwhelm the CPU that deals >with generating cookies, or GB> From experience the cookie mechanism works very well, I have never seen a need for an IPS or similar. > 2. Take the attack to the next level by also sending an Authentication >request. > >I don't think the first thing is something we can deal with at the IKE >leve. It's probably better left to IPS technology. >Sending an Authentication request is surprisingly cheap. It requires a >proper IKE header with the correct IKE SPIs, and it requires a single >encrypted payload. The content of the payload might as well be junk. The >responder has to perform the relatively expensive key derivation, only to >find that the Authentication request does not decrypt. Depending on the >responder implementation, this can be repeated with the same half-open SA >(if the responder does not delete the half-open SA following an >unsuccessful decryption). For extra credit, the attacker can send the >Authentication request just before the entry expires. > >Here too, the number of half-open SAs that the attacker can achieve is >crucial, because each one of them allows the attacker to waste some CPU >time. So making it hard to make many half-open SAs is important. > >A strategy against DDoS has to rely on at least 4 components: > 1. Hardening the half-open SA database by reducing retention time. > 2. Hardening the half-open SA database by rate-limiting single >IPs/prefixes > 3. Guidance on what to do when an Authentication request fails to >decrypt. GB>I'd say this would need to be a number or % of connections, just a single auth failing - we wouldn't want to bring the whole system into some locked down state. For a large number of clients it's common for authentications to fail (from personal experience). > 4. Increasing cost of half-open SA up to what is tolerable for >legitimate clients GB> This 'sweet spot' is crucial, but seems to vary per implementation. > 5. Other things? > >Puzzles have their place as part of #4. I think a WG document should >cover all. > >Yoav > >[1] this could be done in part #1, but that makes the DoS issue worse. >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec --B_3495386241_25648324 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIOeAYJKoZIhvcNAQcCoIIOaTCCDmUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggw+MIIEpzCCA4+gAwIBAgIQZmBP5MZi1b5ckUheWh5wbTANBgkqhkiG9w0BAQUFADBU MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv YmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMB4XDTE0MDEyNTIyNDE0OFoXDTE2MDYw MzExMDA1OFowQDEbMBkGA1UEAwwSZ3JiYXJ0bGVAY2lzY28uY29tMSEwHwYJKoZIhvcNAQkB FhJncmJhcnRsZUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCq YhYxolKrFoPfXuZTQdAiQVFg14EvWwIEMyXxhfH2RiwOSJRSsUVmTNYG8HdeSf0JdzjAMh9p ODgxLC90Q1nbLyBqmEAKElWTasAnATKBCD7aLhce+25cznTT4FDpJsvvU2lZFPWXSLQm3bNR +mEDP6pd8zR1ItOKBlNmGtwypUUvi4KrKRPzx1cSgVTN0Xocj4fC5N8Rj3tOqOns+EHOX4Rw oy/rebHjQyv1cRr6FyGhRuz24hPv8mAGr/iF0cMphAsujaGKyAo+tA05K3nI0fdoeCx2wdEs vo8jIeeZVii07b3K9+VdJQmerVKJyMfQT6gLkyuassY/5aXlglNxAgMBAAGjggGHMIIBgzAO BgNVHQ8BAf8EBAMCBaAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYm aHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wHQYDVR0RBBYwFIESZ3Ji YXJ0bGVAY2lzY28uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3Nw ZXJzb25hbHNpZ24xZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDov L3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24xZzIuY3J0MB0G A1UdDgQWBBRBHvZ1Aur9AFGMEId10iH6yeUX3jAfBgNVHSMEGDAWgBTsrJjMJ3KTz1YyzSPH nY1FhfQiAzANBgkqhkiG9w0BAQUFAAOCAQEAdhq5YZv5ZCu0/HdQF1S3f+quesVc39HKv+Fe 2rmKuJcxfGOFZGpKhJDa1+sFeN/T+e2e6UJ0Yy90GLqi5U1fioD3XRhsFiVOh7CbJQESF2Xx U1bhdutZFh6Ythe28iRPY6HQjJ/7ke5IQBWvLnAbCIzgy0GgZB9Vj+a2z6bzmfR6KAuLaMqM vahvJ0w+DeHMEOVnVzCdZzHMaEOXZHw/uZj5/hGvkp2C0rH/LhGunfAPX12WhVQSsgxWJhaF 8D49Ymrt7PWBsLokx06/15XwY2ogBmfLmeN/WhMy5HUiLn3EnzwF+RK2MStCDpP5AWzdnrTR tM43+AJrHwoI7H+C9DCCBBYwggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUA MFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdS b290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcN MTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1z YTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGjx0+LH0uRqeZCHrYQ7KN3QuahfxY8 fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqDlin3HracDqMRgwrknWuFeqxh N2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQBhcaJA2ucABbUVTHDTxi 7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+OhtnAhrgzrsd4oAy qgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7upoxvV09Fsf7h DeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUdIAAw NDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAf BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7un yEtmt9Ia7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDu vg/OZ0gILDFIa9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVU m5V1tW3XuYNg6SbtcDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVg wb/j/kplOa13nshhc8zULVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5ui B8TZ0s327g44Ylc6dgKgYelNn9RLYjNETX8OIJZlr0tFYpcYrDCCA3UwggJdoAMCAQICCwQA AAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJv b3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7m mY3Oo+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsur HExwB6E9CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8G PIhpWypNxadUuGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounI Cjjr8iQTT3NUkxOFOhu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjI GSvRRqpI1mQq14M0/ywqwWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8 /UswDQYJKoZIhvcNAQEFBQADggEBANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16q EUi25Qijs8o9YU3TRgmzPsOg42NVG/K676054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeY BN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8suWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUM HaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRWMZXQZ4mFK/lspl1GnQyqguSZUd1wt9tW PWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY24GzBBzFH6SAbxUgyd4MiAod1mZV 4vxIySkmaeAxggH+MIIB+gIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzIC EGZgT+TGYtW+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgfZ7o G8eBHKA3vU8sztjppZZE/igrQ2gYUjYly4IQIhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTQxMDA1MTkzNzIxWjANBgkqhkiG9w0BAQEFAASCAQAkkc1b VF07k8rqnPmfK67acFAMvqSLH4mr53DsBVFp56m8/GHbNVOZvKA7jp/dn2o6/FEan3Adj2Rc zu5eaEK1AKWTRpQoek/tsov/SwnPjXgHQ4L4zs5olAc260M+bnZFaA7peq+jI7sqzakyYG9j 4Iz9hVSflaK1GJ/XmA1v1bg1tjnRGdwEY1kpryfbE1yqUyAxQjoJt137m0fGU8ImHY3rljAk LflTndeSKCzz9PDx2TTNV+hO9BrUdGtYPTUihHFqbW6vR0/QmVJQA3OmOpY5NG02h5rWki9G uu2xNCC87jsOoGGpmCeEA+RwZGYRdQqkaiF9GLIdm+fLeh6I --B_3495386241_25648324-- From nobody Sun Oct 5 12:56:37 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3761A1AFC for ; Sun, 5 Oct 2014 12:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XigdewlxNZVo for ; Sun, 5 Oct 2014 12:56:34 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BD6E1A1AFE for ; Sun, 5 Oct 2014 12:56:33 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id pv20so3313156lab.20 for ; Sun, 05 Oct 2014 12:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=KB0grCrLEx6a10axUoDdlrKZoWAolfxsUcWis9zjFNE=; b=lG5xOLKysq/8CzxEntlig0+WU2HQ2U++zm3mQg1tErZGLfyBJHA3HmcfEit6/mpT2C iMveQMfmdTO3/5dgyEhG+ypVcZI0FCpfW9ApTDYlaNYgDGC0dyEM/vVyc8SqimgcfAKz pR7GKVtWUQLxHzYvp6Op5zfp1ptj76MNpyFjOxuc4gQWaTQIATLpHP5aWjj1Viy2NTgv VLLTQ3i79LwtRLRdfBACiDHcMnc+TIosc/kCiEr6TD3ItXDCGr1O0iLcTqvkGCOYubos GWw3nUxe0F4sRTNYO/yZZmdnMv9OpjDT3qdRgXmPfY92L/giVXG37eaanc5QAcbXatcX 151A== X-Received: by 10.112.164.203 with SMTP id ys11mr4466043lbb.83.1412538991094; Sun, 05 Oct 2014 12:56:31 -0700 (PDT) Received: from [10.0.0.6] (bzq-79-178-54-235.red.bezeqint.net. [79.178.54.235]) by mx.google.com with ESMTPSA id i3sm5022783laa.8.2014.10.05.12.56.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Oct 2014 12:56:30 -0700 (PDT) Message-ID: <5431A26C.90307@gmail.com> Date: Sun, 05 Oct 2014 22:56:28 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Yoav Nir , ipsec References: <9612D2B2-7DFE-49F5-8593-3750B781956B@gmail.com> In-Reply-To: <9612D2B2-7DFE-49F5-8593-3750B781956B@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/HlWplNXcqx_iENkVLlk2u6XYkeM Subject: Re: [IPsec] A strategy against DoS/DDoS for IKE responders X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 19:56:36 -0000 Hi Yoav, Thanks for this excellent analysis. A few comments: - When using ECDH, part of the cost of step #2 is validating the incoming DH public key, per RFC 6989. This assumes you are reusing DH parameters, which makes sense in a DoS situation. It may be legit (but strange) to defer this validation to follow the integrity check of the encrypted payload. - I'm not sure what is special about "[the case] when an Authentication request fails to decrypt." Seems to me this is a verified DoS attack from a specific IP. - Your model talks about a single gateway, or a tight cluster of gateways. An advantage of puzzles that goes beyond this model is that even if your gateways do not share information about suspicious IPs, a puzzle generated by each gateway reduces the attacker's power to attack any other gateway. This is much more powerful than rate limiting by any particular gateway. Thanks, Yaron On 10/05/2014 01:25 PM, Yoav Nir wrote: > Hi > > Here are some thoughts about DoS and DDoS protection for an IKE daemon. I think this should be discussed before submitting any drafts, because the acceptance thread reflected that the problem we want to solve is DoS and DDoS, not just the lack of a puzzle mechanism. > > If we break down what a responder has to do during an initial exchange, there are four stages: > > 1. When the Initial request arrives, the responder: > - generates or re-uses a D-H private part. > - generates a responder SPI > - stores the private part and peer public part in a half-open SA database. > > 2. When the Authentication request arrives, the responder: > - derives the keys from the half-open SA ([1]). > - decrypts the request. > > 3. If the Authentication request decrypts properly: > - validates the certificate chain (if present) in the auth request > > Yes, there's a stage 4 where the responder actually derives keys, but when talking about (D)DoS, we never get to this stage. > > Stage #1 is pretty light on CPU power, but requires some storage, and it's very light for the initiator as well. Stage #2 includes private-key operations, so it's much heavier CPU-wise. Stage #3 includes a public key operation, and possibly many of them. > > To attack such a server, an attacker can attempt to either exhaust memory or to exhaust CPU. Without any protection, the best avenue is to send multiple faked Initial requests, and exhaust memory. This should be easy because those Initial requests are cheap. > > There are obvious ways for the responder to protect itself even without changes to the protocol. It can reduce the time that an entry remains in the half-open SA database, and it can limit the amount of concurrent half-open SAs from a particular address or prefix. The attacker can overcome this by using spoofed source addresses. > > The stateless cookie mechanism (that is already in the RFC) prevents an attack with spoofed source addresses. This doesn't solve the issue, but it makes the address or prefix limiting work. Puzzles do the same thing only more of it. They make it harder for an attacker to reach the goal of getting a half-open SA. They don't have to be so hard that an attacker can't afford to solve them - it's enough that they increase the cost of a half-open SAs for the attacker. > > Reducing the amount of time an abandoned half-open SA is kept attacks the issue from the other side. It reduces the value the attacker gets from managing to create a half-open SA. So if a half-open SA takes 1 KB and it's kept for 1 minute and the capacity is 60,000 half-open SAs, an attacker would need to create 1,000 half-open SAs per second. Reduce the retention time to 3 seconds, and the attacker needs to create 20,000 half-open SAs per second. Make each of those more expensive, and you're likely to thwart an exhaustion attack against responder memory. > > At this point, I'm guessing that this is no longer the most efficient DoS attack. The attacker has two ways to do better: > 1. Go back to spoofed addresses and try to overwhelm the CPU that deals with generating cookies, or > 2. Take the attack to the next level by also sending an Authentication request. > > I don't think the first thing is something we can deal with at the IKE leve. It's probably better left to IPS technology. > > Sending an Authentication request is surprisingly cheap. It requires a proper IKE header with the correct IKE SPIs, and it requires a single encrypted payload. The content of the payload might as well be junk. The responder has to perform the relatively expensive key derivation, only to find that the Authentication request does not decrypt. Depending on the responder implementation, this can be repeated with the same half-open SA (if the responder does not delete the half-open SA following an unsuccessful decryption). For extra credit, the attacker can send the Authentication request just before the entry expires. > > Here too, the number of half-open SAs that the attacker can achieve is crucial, because each one of them allows the attacker to waste some CPU time. So making it hard to make many half-open SAs is important. > > A strategy against DDoS has to rely on at least 4 components: > 1. Hardening the half-open SA database by reducing retention time. > 2. Hardening the half-open SA database by rate-limiting single IPs/prefixes > 3. Guidance on what to do when an Authentication request fails to decrypt. > 4. Increasing cost of half-open SA up to what is tolerable for legitimate clients > 5. Other things? > > Puzzles have their place as part of #4. I think a WG document should cover all. > > Yoav > > [1] this could be done in part #1, but that makes the DoS issue worse. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Sun Oct 5 13:22:38 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690A31A1B08 for ; Sun, 5 Oct 2014 13:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ce0EVGW7pKr9 for ; Sun, 5 Oct 2014 13:22:34 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B43611A1B07 for ; Sun, 5 Oct 2014 13:22:33 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id b13so5156336wgh.24 for ; Sun, 05 Oct 2014 13:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=osbuw7Na7tUhg2IXhDUp805T/NrGxM51SAmfuPMkuNI=; b=jjh0cNRNbpHrvPitA7rwk9HkSy/oqz+JyBqThA2WM9d1/Pq6BYb+942X7Vc72/EX4R YlMPHp/rUFNIxVfJAG5iMnkgE5nXufo2OUtmLxeNN8LEXOGTCMkwsYHplPrG2rcZTKZy i6T30ApOevuEiW3iq9xYP+adS9FJbmu26SO1ixiyWQ+BRrxKZdB6cfFenzITjbR3JFTM jQJL/KmTDXh211fvtiBrtWNeVbSSP4DUVOLG1bx7xJRwxyq5XZi6rfM4Ki4uyN99hbnw ru0f6qkzf4JvILac0qX3yBoXIM900G5Dl5+2GxHPbxMcKXXnNXquSgJGW8Qjx+8DI4US Ls0Q== X-Received: by 10.180.75.229 with SMTP id f5mr14187752wiw.81.1412540552306; Sun, 05 Oct 2014 13:22:32 -0700 (PDT) Received: from [192.168.1.100] (IGLD-84-228-54-144.inter.net.il. [84.228.54.144]) by mx.google.com with ESMTPSA id bt9sm14964226wjc.44.2014.10.05.13.22.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 Oct 2014 13:22:31 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <5431A26C.90307@gmail.com> Date: Sun, 5 Oct 2014 23:22:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9612D2B2-7DFE-49F5-8593-3750B781956B@gmail.com> <5431A26C.90307@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/dBKFOpmCoakxCsTH47Vuzaib3EE Cc: ipsec Subject: Re: [IPsec] A strategy against DoS/DDoS for IKE responders X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 20:22:35 -0000 Hi, Yaron On Oct 5, 2014, at 10:56 PM, Yaron Sheffer = wrote: >=20 > - I'm not sure what is special about "[the case] when an = Authentication request fails to decrypt." Seems to me this is a verified = DoS attack from a specific IP. I see I wasn=92t clear about this, because both you and Graham missed = what I meant. Suppose we have a responder where half-open SAs time out after 10 = seconds.=20 This responder receives an Initial Request, and responds with an Initial = Response. It stores its own private value and the peer=92s public value in the = half-open SA database, keyed by IKE SPIs. 0.5 seconds later, it receives an IKE_AUTH request with the right IKE = SPIs. It derives the keys (making any ECDH check that=92s needed) It tries to decrypt the message The message fails to decrypt (or more likely, the MAC comparison fails) Now the responder has two options: (1) delete the entry in the half-open SA database, or (2) store the derived key, and keep the half-open SA another 9.5 = seconds. (2) has the disadvantage that the attacker can keep sending more junk = packets and get the responder to attempt to decrypt all of them. (1) has the disadvantage that an attacker can inject a junk IKE_AUTH = request by just copying the IKE SPIs from the IKE_INIT response, which = will prevent the responder from processing the real initiator=92s = IKE_AUTH request. So I=92m not sure which is worse. Yoav From nobody Sun Oct 5 18:21:10 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8621A0270 for ; Sun, 5 Oct 2014 18:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bysvbYYx30LZ for ; Sun, 5 Oct 2014 18:21:02 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 240FB1A026E for ; Sun, 5 Oct 2014 18:21:02 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id D67589405E; Sun, 5 Oct 2014 18:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=ToNeSj0SgcRJPcoSBFHdLQphock=; b=faE4N3UGlh5 Kxd3h4YTLCK0TTcFqCYO6G20/5qoi/XPvEE4f1vfInkogHFZMmVN5a6PhU/1yCi9 E4Ba0JBI0EBEnOoUTwlmXlRvkuCxdfrYD2LpWuGlqkmttq4xO3OlDOTa5VJoPR45 2gzp2uG5ls+QN7l200N6eqFJO8A/0f4k= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPA id 9274B9405C; Sun, 5 Oct 2014 18:21:01 -0700 (PDT) Date: Sun, 5 Oct 2014 20:21:01 -0500 From: Nico Williams To: Yoav Nir Message-ID: <20141006012059.GE14969@localhost> References: <9612D2B2-7DFE-49F5-8593-3750B781956B@gmail.com> <5431A26C.90307@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/RbA5YTawHu233X4Lg0egUNlrWxk Cc: ipsec Subject: Re: [IPsec] A strategy against DoS/DDoS for IKE responders X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 01:21:03 -0000 On Sun, Oct 05, 2014 at 11:22:29PM +0300, Yoav Nir wrote: > Now the responder has two options: > (1) delete the entry in the half-open SA database, or > (2) store the derived key, and keep the half-open SA another 9.5 secon= ds. >=20 > (2) has the disadvantage that the attacker can keep sending more junk p= ackets and get the responder to attempt to decrypt all of them. > (1) has the disadvantage that an attacker can inject a junk IKE_AUTH re= quest by just copying the IKE SPIs from the IKE_INIT response, which will= prevent the responder from processing the real initiator=E2=80=99s IKE_A= UTH request. >=20 > So I=E2=80=99m not sure which is worse. Split the difference. Shorten the amount of time you keep the half-open SA around. The amount of time to keep a half-open SA/connection/state around should be dynamic: based on something like N standard deviations from the average time to complete a handshake when not under (D)DoS attack. 10 seconds is a lot!! If you're going to use OTP -any interactive authentication- then that should really be done as one more round-trip. Human interface factors should not be allowed to interfere at this stage. The old internal Sun punchin VPN did user authentication and authorization after setting up SAs; success led to the necessary routing getting setup so the user's bits moved. Nico --=20 From nobody Mon Oct 6 01:31:44 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDE91A1A79 for ; Mon, 6 Oct 2014 01:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.773 X-Spam-Level: X-Spam-Status: No, score=-13.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rjj6QpCSzyp for ; Mon, 6 Oct 2014 01:31:40 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB8A1A1A7F for ; Mon, 6 Oct 2014 01:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8813; q=dns/txt; s=iport; t=1412584300; x=1413793900; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qzGLX5aP2Ukw+556r28nk1loSJFwaKSqpZOa/bIDqFM=; b=BtVjpKdxMqwlcDbq+Q45PS0184whk+G+FlTYL3SapvT/gUAFa9g8JlJY Ds0UEvEnArENt66SIoBbM31hFDRVzquq6t/fqIB9lug34IxNuT8ML7Ay5 le81v0/AZAAgQB1/5fXiriC7G3Z4fSuvY0GMq/qYul03x0eJP6K+L3/to Y=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYHAARTMlStJA2J/2dsb2JhbABfgmsjU1gEzAkKgzKEGwKBBBYBe4QEAQEEAQEBawsQAgEIDgouAh8GCyUCBAENBQ6IHAMRAQy4Gw2HGAETBIJhizOCFhsHhEsFix2GV4ILgUyFYoIRjy+GUYNjbIEGBgE7gQIBAQE X-IronPort-AV: E=Sophos;i="5.04,662,1406592000"; d="p7s'?scan'208";a="84261969" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP; 06 Oct 2014 08:31:39 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s968Vduj010419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Oct 2014 08:31:39 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Mon, 6 Oct 2014 03:31:39 -0500 From: "Graham Bartlett (grbartle)" To: Yoav Nir , Yaron Sheffer Thread-Topic: [IPsec] A strategy against DoS/DDoS for IKE responders Thread-Index: AQHP4IbF+Xf2zTD2ikCTmGddD9T/C5wiP6oAgAAHRYCAANx7gA== Date: Mon, 6 Oct 2014 08:31:38 +0000 Message-ID: References: <9612D2B2-7DFE-49F5-8593-3750B781956B@gmail.com> <5431A26C.90307@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.55.146.101] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3495432697_26222351" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/EJbRoLQPnEHuHX5SMakVn8Ovq48 Cc: ipsec Subject: Re: [IPsec] A strategy against DoS/DDoS for IKE responders X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 08:31:42 -0000 --B_3495432697_26222351 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi This is a very interesting attack, I would dismiss (1) as it leaves an implementation open for a semi-easy DOS (just one packet that generates work rate on both initiator and responder). Basing the behaviour on (2) the attacker would only have the window from when the responder sends the SA_INIT, to receiving the (valid) IKE_AUTH. As Nico said shortening the time is critical, but also once the responder receives a valid IKE_AUTH it should (IMO) dismiss any more IKE_AUTH messages it receives. I guess you could look at rate limiting IKE_AUTH messages if they fail to decrypt, but then you could drop the legit IKE_AUTH. Unless the attacker is very very lucky (in their packet generation), or has the authentication credentials they will not be able to send a valid IKE_AUTH, so the window that occurs between the responder receiving the valid IKE_AUTH is key. I see the potential for an attacker dropping, or delaying the legit IKE_AUTH and then sending many IKE_AUTH as you said, so if the behaviour was set to 10s if a device detected it was under this attack it should reduce the window of time to process IKE_AUTH (as Nico said), but once again this could then drop the legit IKE_AUTH. As I understand the RFC6989 checks are performed on the public value received in SA_INIT, no IKE_AUTH. (FROM RFC6989) "A receiving peer MUST check that its peer's public value is valid;", so these checks (as I understand) would be performed before the responder sends the SA_INIT. So to summarise, I think that (1) is worse, (2) should be implemented (maybe with a different timer), but with guidance on what to do should a device become under attack. cheers On 05/10/2014 21:22, "Yoav Nir" wrote: >Hi, Yaron > >On Oct 5, 2014, at 10:56 PM, Yaron Sheffer wrote: > >>=20 >> - I'm not sure what is special about "[the case] when an Authentication >>request fails to decrypt." Seems to me this is a verified DoS attack >>from a specific IP. > >I see I wasn=B9t clear about this, because both you and Graham missed what >I meant. > >Suppose we have a responder where half-open SAs time out after 10 >seconds.=20 >This responder receives an Initial Request, and responds with an Initial >Response. >It stores its own private value and the peer=B9s public value in the >half-open SA database, keyed by IKE SPIs. >0.5 seconds later, it receives an IKE_AUTH request with the right IKE >SPIs. >It derives the keys (making any ECDH check that=B9s needed) >It tries to decrypt the message >The message fails to decrypt (or more likely, the MAC comparison fails) >Now the responder has two options: > (1) delete the entry in the half-open SA database, or > (2) store the derived key, and keep the half-open SA another 9.5 seconds. > >(2) has the disadvantage that the attacker can keep sending more junk >packets and get the responder to attempt to decrypt all of them. >(1) has the disadvantage that an attacker can inject a junk IKE_AUTH >request by just copying the IKE SPIs from the IKE_INIT response, which >will prevent the responder from processing the real initiator=B9s IKE_AUTH >request. > >So I=B9m not sure which is worse. > >Yoav > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec --B_3495432697_26222351 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIOeAYJKoZIhvcNAQcCoIIOaTCCDmUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggw+MIIEpzCCA4+gAwIBAgIQZmBP5MZi1b5ckUheWh5wbTANBgkqhkiG9w0BAQUFADBU MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv YmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMB4XDTE0MDEyNTIyNDE0OFoXDTE2MDYw MzExMDA1OFowQDEbMBkGA1UEAwwSZ3JiYXJ0bGVAY2lzY28uY29tMSEwHwYJKoZIhvcNAQkB FhJncmJhcnRsZUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCq YhYxolKrFoPfXuZTQdAiQVFg14EvWwIEMyXxhfH2RiwOSJRSsUVmTNYG8HdeSf0JdzjAMh9p ODgxLC90Q1nbLyBqmEAKElWTasAnATKBCD7aLhce+25cznTT4FDpJsvvU2lZFPWXSLQm3bNR +mEDP6pd8zR1ItOKBlNmGtwypUUvi4KrKRPzx1cSgVTN0Xocj4fC5N8Rj3tOqOns+EHOX4Rw oy/rebHjQyv1cRr6FyGhRuz24hPv8mAGr/iF0cMphAsujaGKyAo+tA05K3nI0fdoeCx2wdEs vo8jIeeZVii07b3K9+VdJQmerVKJyMfQT6gLkyuassY/5aXlglNxAgMBAAGjggGHMIIBgzAO BgNVHQ8BAf8EBAMCBaAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYm aHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wHQYDVR0RBBYwFIESZ3Ji YXJ0bGVAY2lzY28uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3Nw ZXJzb25hbHNpZ24xZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDov L3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24xZzIuY3J0MB0G A1UdDgQWBBRBHvZ1Aur9AFGMEId10iH6yeUX3jAfBgNVHSMEGDAWgBTsrJjMJ3KTz1YyzSPH nY1FhfQiAzANBgkqhkiG9w0BAQUFAAOCAQEAdhq5YZv5ZCu0/HdQF1S3f+quesVc39HKv+Fe 2rmKuJcxfGOFZGpKhJDa1+sFeN/T+e2e6UJ0Yy90GLqi5U1fioD3XRhsFiVOh7CbJQESF2Xx U1bhdutZFh6Ythe28iRPY6HQjJ/7ke5IQBWvLnAbCIzgy0GgZB9Vj+a2z6bzmfR6KAuLaMqM vahvJ0w+DeHMEOVnVzCdZzHMaEOXZHw/uZj5/hGvkp2C0rH/LhGunfAPX12WhVQSsgxWJhaF 8D49Ymrt7PWBsLokx06/15XwY2ogBmfLmeN/WhMy5HUiLn3EnzwF+RK2MStCDpP5AWzdnrTR tM43+AJrHwoI7H+C9DCCBBYwggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUA MFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdS b290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcN MTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1z YTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGjx0+LH0uRqeZCHrYQ7KN3QuahfxY8 fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqDlin3HracDqMRgwrknWuFeqxh N2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQBhcaJA2ucABbUVTHDTxi 7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+OhtnAhrgzrsd4oAy qgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7upoxvV09Fsf7h DeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUdIAAw NDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAf BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7un yEtmt9Ia7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDu vg/OZ0gILDFIa9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVU m5V1tW3XuYNg6SbtcDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVg wb/j/kplOa13nshhc8zULVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5ui B8TZ0s327g44Ylc6dgKgYelNn9RLYjNETX8OIJZlr0tFYpcYrDCCA3UwggJdoAMCAQICCwQA AAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJv b3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7m mY3Oo+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsur HExwB6E9CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8G PIhpWypNxadUuGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounI Cjjr8iQTT3NUkxOFOhu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjI GSvRRqpI1mQq14M0/ywqwWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8 /UswDQYJKoZIhvcNAQEFBQADggEBANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16q EUi25Qijs8o9YU3TRgmzPsOg42NVG/K676054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeY BN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8suWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUM HaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRWMZXQZ4mFK/lspl1GnQyqguSZUd1wt9tW PWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY24GzBBzFH6SAbxUgyd4MiAod1mZV 4vxIySkmaeAxggH+MIIB+gIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzIC EGZgT+TGYtW+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgH19f vQMOtdpg/Fj/ozvCsvaxZt4qffGxqs/NSBThiOswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTQxMDA2MDgzMTM3WjANBgkqhkiG9w0BAQEFAASCAQA+Cu0M o6JzjVvekX7/5KMto42LvrkWLf810seu++ix9HUrl1f1DNXzdKXu35E5cXpdnQtlzy+tXPxQ C2KBkTkqmJIyCexKPOWTSnnGaLKO1F8wTePTlvsMXtlmzC3jMFzcXFWBCxocovnMbjUE3Zk2 8Zy6oWVXaPLZflWF1tzorzrk1WZInZBqquhKpxhKYB5OTP+tkf4NyAgMA0sVJF7P4n2JACDV sWRP9/gtHzV3dJYS5FagM1SO9rM9+Ph+wyjSJHFgbWBzEcwCOxl/t3g0DvxjJj8ygkkzBiBx xSWpdFVdNeCWEKj8ufX2x2mzRAPLQPExguDWO6ZbQMsMDtF5 --B_3495432697_26222351-- From nobody Mon Oct 6 12:31:58 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A957E1A1AD7 for ; Mon, 6 Oct 2014 12:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRHaU00EEpXj for ; Mon, 6 Oct 2014 12:31:53 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311921A1AD4 for ; Mon, 6 Oct 2014 12:31:53 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hi2so5683870wib.15 for ; Mon, 06 Oct 2014 12:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=MWqmsHoSDyNnFWj2t7L/006wT3MvkwYXQ8HBTwr1u6U=; b=kA7dkvct8UBD4K//WMnTcnMgVQrEqXXLM892lNkYmthfP+bkRe4ZzpmR56U0vtuBYg 9rdEKhdO8k6N1AHyq/oJIctDxZbz2quuHHYTXf8VnxmOdHa7f1Tf3Jza0HUq2FyVBqIt nteLwvLBqPYUt2bI0LnxmZ7yPOELwK9b+mBR1vGoK+IoxqLSDPI62qynXbkRsgWLt6OM BMeTGMLOGHBRXL3CkrmUWB9RrgsPVW/pCKhj9MHLAFLitJbg7kERwupVXFULVWVZfdqY iMnzDvirQu+ER70Ef2/drQnzeeMq19ZeGnkMnm7zOUPFCmAbtmAq74wWpjYJZrPXJTj+ oM2Q== X-Received: by 10.194.77.42 with SMTP id p10mr6039509wjw.125.1412623911829; Mon, 06 Oct 2014 12:31:51 -0700 (PDT) Received: from [10.0.0.6] (bzq-79-178-54-235.red.bezeqint.net. [79.178.54.235]) by mx.google.com with ESMTPSA id u2sm18275905wjz.11.2014.10.06.12.31.50 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Oct 2014 12:31:51 -0700 (PDT) Message-ID: <5432EE25.7050400@gmail.com> Date: Mon, 06 Oct 2014 22:31:49 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Graham Bartlett (grbartle)" , Yoav Nir References: <9612D2B2-7DFE-49F5-8593-3750B781956B@gmail.com> <5431A26C.90307@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/u92lPxcIhYqO618Ax3ibv1bo0J4 Cc: ipsec Subject: Re: [IPsec] A strategy against DoS/DDoS for IKE responders X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 19:31:55 -0000 It seems to me the difference between the two options is not very important (assuming reasonable rate limits), because the cost of receiving an IKE_AUTH message and detecting an incorrect MAC is not very high, after the initial generation of the IKE SA key material. But Yoav's model also demonstrates that we could get the same effect by attaching the puzzle to IKE_AUTH - though I don't see an advantage. Re: RFC 6989, yes, the test refers to IKE_SA_INIT. But the response message does not depend on the received DH public key, so IMHO it's fine to postpone the test until IKE_AUTH is received, and before generating the IKE shared key. Thanks, Yaron On 10/06/2014 11:31 AM, Graham Bartlett (grbartle) wrote: > Hi > > This is a very interesting attack, I would dismiss (1) as it leaves an > implementation open for a semi-easy DOS (just one packet that generates > work rate on both initiator and responder). > > Basing the behaviour on (2) the attacker would only have the window from > when the responder sends the SA_INIT, to receiving the (valid) IKE_AUTH. > As Nico said shortening the time is critical, but also once the responder > receives a valid IKE_AUTH it should (IMO) dismiss any more IKE_AUTH > messages it receives. > > > I guess you could look at rate limiting IKE_AUTH messages if they fail to > decrypt, but then you could drop the legit IKE_AUTH. Unless the attacker > is very very lucky (in their packet generation), or has the authentication > credentials they will not be able to send a valid IKE_AUTH, so the window > that occurs between the responder receiving the valid IKE_AUTH is key. > > I see the potential for an attacker dropping, or delaying the legit > IKE_AUTH and then sending many IKE_AUTH as you said, so if the behaviour > was set to 10s if a device detected it was under this attack it should > reduce the window of time to process IKE_AUTH (as Nico said), but once > again this could then drop the legit IKE_AUTH. > > As I understand the RFC6989 checks are performed on the public value > received in SA_INIT, no IKE_AUTH. (FROM RFC6989) "A receiving peer MUST > check that its peer's public value is valid;", so these checks (as I > understand) would be performed before the responder sends the SA_INIT. > > So to summarise, I think that (1) is worse, (2) should be implemented > (maybe with a different timer), but with guidance on what to do should a > device become under attack. > > cheers > > > > On 05/10/2014 21:22, "Yoav Nir" wrote: > >> Hi, Yaron >> >> On Oct 5, 2014, at 10:56 PM, Yaron Sheffer wrote: >> >>> >>> - I'm not sure what is special about "[the case] when an Authentication >>> request fails to decrypt." Seems to me this is a verified DoS attack >> >from a specific IP. >> >> I see I wasn¹t clear about this, because both you and Graham missed what >> I meant. >> >> Suppose we have a responder where half-open SAs time out after 10 >> seconds. >> This responder receives an Initial Request, and responds with an Initial >> Response. >> It stores its own private value and the peer¹s public value in the >> half-open SA database, keyed by IKE SPIs. >> 0.5 seconds later, it receives an IKE_AUTH request with the right IKE >> SPIs. >> It derives the keys (making any ECDH check that¹s needed) >> It tries to decrypt the message >> The message fails to decrypt (or more likely, the MAC comparison fails) >> Now the responder has two options: >> (1) delete the entry in the half-open SA database, or >> (2) store the derived key, and keep the half-open SA another 9.5 seconds. >> >> (2) has the disadvantage that the attacker can keep sending more junk >> packets and get the responder to attempt to decrypt all of them. >> (1) has the disadvantage that an attacker can inject a junk IKE_AUTH >> request by just copying the IKE SPIs from the IKE_INIT response, which >> will prevent the responder from processing the real initiator¹s IKE_AUTH >> request. >> >> So I¹m not sure which is worse. >> >> Yoav >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Oct 7 07:24:13 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719141ACDB7 for ; Tue, 7 Oct 2014 07:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2StQ1LutN58m for ; Tue, 7 Oct 2014 07:24:07 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28BA1A6F04 for ; Tue, 7 Oct 2014 07:24:06 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s97EO4eA024329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 Oct 2014 17:24:04 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s97EO373004959; Tue, 7 Oct 2014 17:24:03 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21555.63363.628296.93775@fireball.kivinen.iki.fi> Date: Tue, 7 Oct 2014 17:24:03 +0300 From: Tero Kivinen To: Johannes Merkle In-Reply-To: <53D225B4.2030508@secunet.com> References: <20140701161112.18036.94027.idtracker@ietfa.amsl.com> <53B6BA3F.40509@secunet.com> <21452.4707.784185.458764@fireball.kivinen.iki.fi> <53D225B4.2030508@secunet.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 18 min X-Total-Time: 20 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/K-KMyGrVKmB99OZGX6AKBwHe5YU Cc: ipsec@ietf.org Subject: Re: [IPsec] Last Call: (Signature Authentication in IKEv2) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 14:24:11 -0000 Johannes Merkle writes: > thanks for updating the document. However, I'm not sure the first > issue is solved. Sorry this has taken so long, having the IEEE, IETF, Vacation and RFC5996bis to taken care of before getting back to this draft. > Tero Kivinen wrote on 20.07.2014 21:02: > > Changed to: > > > > With RSASSA-PSS, the algorithm object identifier must always > > be id-RSASSA-PSS, and the hash function and padding parameters > > are conveyed in the parameters (which are not optional in this > > case). See for more information. > > > > In the RSASSA-PSS the parameters are required, but they can be empty, > > so they are not optional in this case. > > > > Really? Section 3.1 of RFC 4055 states > When RSASSA-PSS is used in an AlgorithmIdentifier, the parameters > MUST employ the RSASSA-PSS-params syntax. The parameters may be > either absent or present when used as subject public key information. > > My understanding of this is that the parameters can indeed be absent > not just empty. After reading RFCs 3447, 4055 and 5912, I think that is not true. > IMHO the semantic is different: If the parameters are empty (empty > sequence in RSASSA-PSS-param), the default values apply, and > according to Section 3.3, case 3, of RFC 4055, the parameters in a > signature MUST be validated against the (default) parameters > specified in SPKI. However, if the parameters are absent, then, > according to Section 3.3, case 2, of RFC 4055, no parameter > validation is needed in a signature validation, i.e. a signature may > use any parameters. > > Maybe, I misinterpret the spec here? RFC 3447 says: ---------------------------------------------------------------------- Appendix C. ASN.1 module ... -- When id-RSASSA-PSS is used in an AlgorithmIdentifier the -- parameters MUST be present and MUST be RSASSA-PSS-params. -- id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } ... -- -- AlgorithmIdentifier.parameters for id-RSASSA-PSS. -- Note that the tags in this Sequence are explicit. -- RSASSA-PSS-params ::= SEQUENCE { hashAlgorithm [0] HashAlgorithm DEFAULT sha1, maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1, saltLength [2] INTEGER DEFAULT 20, trailerField [3] TrailerField DEFAULT trailerFieldBC } ... -- -- Identifier for default RSASSA-PSS algorithm identifier -- The DER Encoding of this is in hexadecimal: -- (0x)30 0D -- 06 09 -- 2A 86 48 86 F7 0D 01 01 0A -- 30 00 -- Notice that the DER encoding of default values is "empty". ---------------------------------------------------------------------- RFC4055 says: ---------------------------------------------------------------------- 3. RSASSA-PSS Signature Algorithm ... ... CAs that use the RSASSA-PSS algorithm for signing certificates or CRLs MUST include RSASSA-PSS- params in the signatureAlgorithm parameters in the TBSCertificate or TBSCertList structures. ... 3.1. RSASSA-PSS Public Keys ... The parameters MUST be present when used in the algorithm identifier associated with a signature value. ---------------------------------------------------------------------- I.e. the next sentence after your quoted section says that for signatures the parameters MUST be present. They can be absent or present when talking about subject public key information, but not for signature. The ASN.1 is not very clear on this as it says only: ---------------------------------------------------------------------- 6. ASN.1 Module ... -- When id-RSASSA-PSS is used in an AlgorithmIdentifier, and the -- parameters field is present, it MUST be RSASSA-PSS-params. id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } ... -- AlgorithmIdentifier parameters for id-RSASSA-PSS. -- Note that the tags in this Sequence are explicit. RSASSA-PSS-params ::= SEQUENCE { hashAlgorithm [0] HashAlgorithm DEFAULT sha1Identifier, maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1Identifier, saltLength [2] INTEGER DEFAULT 20, trailerField [3] INTEGER DEFAULT 1 } ---------------------------------------------------------------------- RFC5912 is more clear about this in ASN.1: ---------------------------------------------------------------------- 8. ASN.1 Module for RFC 4055 -- ============================= -- Algorithm Objects -- ============================= -- -- Public key object for PSS signatures -- pk-rsaSSA-PSS PUBLIC-KEY ::= { IDENTIFIER id-RSASSA-PSS KEY RSAPublicKey PARAMS TYPE RSASSA-PSS-params ARE optional -- Private key format not in this module -- CERT-KEY-USAGE { nonRepudiation, digitalSignature, keyCertSign, cRLSign } } -- -- Signature algorithm definition for PSS signatures -- sa-rsaSSA-PSS SIGNATURE-ALGORITHM ::= { IDENTIFIER id-RSASSA-PSS PARAMS TYPE RSASSA-PSS-params ARE required HASHES { mda-sha1 | mda-sha224 | mda-sha256 | mda-sha384 | mda-sha512 } PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS } SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS } } ... -- When id-RSASSA-PSS is used in an AlgorithmIdentifier, and the -- parameters field is present, it MUST be RSASSA-PSS-params. id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } ... -- AlgorithmIdentifier parameters for id-RSASSA-PSS. -- Note that the tags in this Sequence are explicit. -- Note: The hash algorithm in hashAlgorithm and in -- maskGenAlgorithm should be the same. RSASSA-PSS-params ::= SEQUENCE { hashAlgorithm [0] HashAlgorithm DEFAULT sha1Identifier, maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1, saltLength [2] INTEGER DEFAULT 20, trailerField [3] INTEGER DEFAULT 1 } ---------------------------------------------------------------------- I.e you can clearly see that in the public key object for PSS signatures the RSASSA-PSS-params are optional, but for the signature algorithm definition for PSS signatures the RSASSA-PSS-params are required. The actual content of the sequence can be empty, but the sequence MUST be there. So the current text saying that the params are not optional in this case is correct. The A.4.1 has example of empty parameters, where there is the id-RSASSA-PSS object identifier and empty sequence after that. Note, that the hex for that matches the hex in RFC3447... -- kivinen@iki.fi From nobody Tue Oct 7 08:46:38 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB961ACE2B for ; Tue, 7 Oct 2014 08:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nFE3au8wxfR for ; Tue, 7 Oct 2014 08:46:29 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0F11ACE1D for ; Tue, 7 Oct 2014 08:46:28 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id D2B3B1A007F; Tue, 7 Oct 2014 17:46:20 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jIlFfbODGHKQ; Tue, 7 Oct 2014 17:46:11 +0200 (CEST) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id CA2661A007C; Tue, 7 Oct 2014 17:46:11 +0200 (CEST) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 7 Oct 2014 17:46:17 +0200 Message-ID: <54340AC8.4070909@secunet.com> Date: Tue, 7 Oct 2014 17:46:16 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tero Kivinen References: <20140701161112.18036.94027.idtracker@ietfa.amsl.com> <53B6BA3F.40509@secunet.com> <21452.4707.784185.458764@fireball.kivinen.iki.fi> <53D225B4.2030508@secunet.com> <21555.63363.628296.93775@fireball.kivinen.iki.fi> In-Reply-To: <21555.63363.628296.93775@fireball.kivinen.iki.fi> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/IuEzai7iLkP-82nN3IFb_UG1UK8 Cc: ipsec@ietf.org Subject: Re: [IPsec] Last Call: (Signature Authentication in IKEv2) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 15:46:36 -0000 Tero Kivinen wrote on 07.10.2014 16:24: > I.e you can clearly see that in the public key object for PSS > signatures the RSASSA-PSS-params are optional, but for the signature > algorithm definition for PSS signatures the RSASSA-PSS-params are > required. The actual content of the sequence can be empty, but the > sequence MUST be there. I agree with that. > > So the current text saying that the params are not optional in this > case is correct. The A.4.1 has example of empty parameters, where > there is the id-RSASSA-PSS object identifier and empty sequence after > that. Note, that the hex for that matches the hex in RFC3447... I was mistaken in thinking that the SubjectPublicKey Identifier is used, but, of course, it is the signatureAlgoithm Identifier. So I was completely wrong here. Issue closed. -- Johannes From nobody Fri Oct 10 04:32:04 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E238A1A8A97 for ; Fri, 10 Oct 2014 04:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyMOxJdjyZEe for ; Fri, 10 Oct 2014 04:32:00 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6861A8AA8 for ; Fri, 10 Oct 2014 04:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11984; q=dns/txt; s=iport; t=1412940719; x=1414150319; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kJtO7+tCM93tkRK09T8HlrOzwNlFo9k0oDTjXDfgiaE=; b=UpvFykuQw1FeC0pkRBJC0k7kwEeAbkDc8f8YkFM0UjV8cL4i4ylnR8j3 jFCdZB9dYu5B39JgpgoDqd2M8Wi5kuZ8JpmaEnhbcgHT4srk7AKmqc0fD DiLOlxw7QVPHI1nUwRiAwaNRJI6OVRLoQLqcp/jCQMAZrabFDWp7ZesJa Q=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAFDCN1StJV2d/2dsb2JhbABWCoJrI1NYBIMCyEEKh00CgQgWAXuEAwEBAQMBAQEBaQILEAIBCBgsAgIfBgslAgQBDQUODYgPAwkIAQyRFpxFBo4cDYZjAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSCYYsxgVZBGweCcYFaBZF5ggyBT4VmghGPPYZUggYYgVlsgQYGATuBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,691,1406592000"; d="p7s'?scan'208";a="85760820" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 10 Oct 2014 11:31:59 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9ABVxqI020859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Oct 2014 11:31:59 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Fri, 10 Oct 2014 06:31:58 -0500 From: "Graham Bartlett (grbartle)" To: Yaron Sheffer , Yoav Nir Thread-Topic: [IPsec] A strategy against DoS/DDoS for IKE responders Thread-Index: AQHP4IbF+Xf2zTD2ikCTmGddD9T/C5wiP6oAgAAHRYCAANx7gIAAp7KAgAXUBQA= Date: Fri, 10 Oct 2014 11:31:58 +0000 Message-ID: References: <9612D2B2-7DFE-49F5-8593-3750B781956B@gmail.com> <5431A26C.90307@gmail.com> <5432EE25.7050400@gmail.com> In-Reply-To: <5432EE25.7050400@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.55.146.102] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3495789118_36187111" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/7gow_OgYVm_xEY9ARJpxBCnAL4M Cc: ipsec Subject: Re: [IPsec] A strategy against DoS/DDoS for IKE responders X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 11:32:03 -0000 --B_3495789118_36187111 Content-type: text/plain; charset="EUC-KR" Content-transfer-encoding: quoted-printable Hi Yaron / Yoav I'm summarising my thoughts below, I've spoken to a few folk offlist and hopefully the following will help my understanding and also theirs. So assuming a device is under potential attack by devices using their own addresses (botnet or similar), the cookie notification is not going to give any benefit (as they are using a legitimate IP address), but Yoav's puzzle will slow the attack down. If an attacker sent a legitimate DH public value (that would pass the 6989 checks) and we held off checking this until IKE_AUTH, as you say no benefit would be gained from detecting this at SA_INIT. The only point in this attack that we detect an attacker is when the AUTH value is known to be incorrect so even if they send correct DH public values. Now the only issue I can see is alluded to in the draft, where a VPN headend is serving clients with varying resource. So say a botnet attacks this headend and the puzzle is enabled, you have some clients with a lot of resource (that require a hard puzzle) and some mobile devices with minimal (that require an easier puzzle). How do you identify each? The only way I can think is you must do this once the device has authenticated itself - else how do you know who they are? An idea - for example the minimum difficulty of the puzzle is sent by responder and this is selected by the client and confirmed by the headend based on IKE ID/certificate attribute? For IKE ID/cert that knows it should perform a harder puzzle it will (manual local setting). I know this is a bit of a corner case, but seems to be an easy attack for someone to start disrupting a remote-access VPN solution that serves clients with different processing resource. So to summarise; Because of the attack(s) described in 6989 I personally feel that this should always be implemented - it's a must. Cookie notification gives no benefit (only mitigates blind spoofing), but Yoav's puzzle will help slow down an attack using a devices own IP address. So I'm all for Yoav's puzzle. :-) cheers=20 On 06/10/2014 20:31, "Yaron Sheffer" wrote: >It seems to me the difference between the two options is not very >important (assuming reasonable rate limits), because the cost of >receiving an IKE_AUTH message and detecting an incorrect MAC is not very >high, after the initial generation of the IKE SA key material. > >But Yoav's model also demonstrates that we could get the same effect by >attaching the puzzle to IKE_AUTH - though I don't see an advantage. > >Re: RFC 6989, yes, the test refers to IKE_SA_INIT. But the response >message does not depend on the received DH public key, so IMHO it's fine >to postpone the test until IKE_AUTH is received, and before generating >the IKE shared key. > >Thanks, > Yaron > > >On 10/06/2014 11:31 AM, Graham Bartlett (grbartle) wrote: >> Hi >> >> This is a very interesting attack, I would dismiss (1) as it leaves an >> implementation open for a semi-easy DOS (just one packet that generates >> work rate on both initiator and responder). >> >> Basing the behaviour on (2) the attacker would only have the window from >> when the responder sends the SA_INIT, to receiving the (valid) IKE_AUTH. >> As Nico said shortening the time is critical, but also once the >>responder >> receives a valid IKE_AUTH it should (IMO) dismiss any more IKE_AUTH >> messages it receives. >> >> >> I guess you could look at rate limiting IKE_AUTH messages if they fail >>to >> decrypt, but then you could drop the legit IKE_AUTH. Unless the attacker >> is very very lucky (in their packet generation), or has the >>authentication >> credentials they will not be able to send a valid IKE_AUTH, so the >>window >> that occurs between the responder receiving the valid IKE_AUTH is key. >> >> I see the potential for an attacker dropping, or delaying the legit >> IKE_AUTH and then sending many IKE_AUTH as you said, so if the behaviour >> was set to 10s if a device detected it was under this attack it should >> reduce the window of time to process IKE_AUTH (as Nico said), but once >> again this could then drop the legit IKE_AUTH. >> >> As I understand the RFC6989 checks are performed on the public value >> received in SA_INIT, no IKE_AUTH. (FROM RFC6989) "A receiving peer MUST >> check that its peer's public value is valid;", so these checks (as I >> understand) would be performed before the responder sends the SA_INIT. >> >> So to summarise, I think that (1) is worse, (2) should be implemented >> (maybe with a different timer), but with guidance on what to do should a >> device become under attack. >> >> cheers >> >> >> >> On 05/10/2014 21:22, "Yoav Nir" wrote: >> >>> Hi, Yaron >>> >>> On Oct 5, 2014, at 10:56 PM, Yaron Sheffer >>>wrote: >>> >>>> >>>> - I'm not sure what is special about "[the case] when an >>>>Authentication >>>> request fails to decrypt." Seems to me this is a verified DoS attack >>> >from a specific IP. >>> >>> I see I wasn=A9=F6t clear about this, because both you and Graham missed >>>what >>> I meant. >>> >>> Suppose we have a responder where half-open SAs time out after 10 >>> seconds. >>> This responder receives an Initial Request, and responds with an >>>Initial >>> Response. >>> It stores its own private value and the peer=A9=F6s public value in the >>> half-open SA database, keyed by IKE SPIs. >>> 0.5 seconds later, it receives an IKE_AUTH request with the right IKE >>> SPIs. >>> It derives the keys (making any ECDH check that=A9=F6s needed) >>> It tries to decrypt the message >>> The message fails to decrypt (or more likely, the MAC comparison fails) >>> Now the responder has two options: >>> (1) delete the entry in the half-open SA database, or >>> (2) store the derived key, and keep the half-open SA another 9.5 >>>seconds. >>> >>> (2) has the disadvantage that the attacker can keep sending more junk >>> packets and get the responder to attempt to decrypt all of them. >>> (1) has the disadvantage that an attacker can inject a junk IKE_AUTH >>> request by just copying the IKE SPIs from the IKE_INIT response, which >>> will prevent the responder from processing the real initiator=A9=F6s >>>IKE_AUTH >>> request. >>> >>> So I=A9=F6m not sure which is worse. >>> >>> Yoav >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec --B_3495789118_36187111 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIOeAYJKoZIhvcNAQcCoIIOaTCCDmUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggw+MIIEpzCCA4+gAwIBAgIQZmBP5MZi1b5ckUheWh5wbTANBgkqhkiG9w0BAQUFADBU MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv YmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMB4XDTE0MDEyNTIyNDE0OFoXDTE2MDYw MzExMDA1OFowQDEbMBkGA1UEAwwSZ3JiYXJ0bGVAY2lzY28uY29tMSEwHwYJKoZIhvcNAQkB FhJncmJhcnRsZUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCq YhYxolKrFoPfXuZTQdAiQVFg14EvWwIEMyXxhfH2RiwOSJRSsUVmTNYG8HdeSf0JdzjAMh9p ODgxLC90Q1nbLyBqmEAKElWTasAnATKBCD7aLhce+25cznTT4FDpJsvvU2lZFPWXSLQm3bNR +mEDP6pd8zR1ItOKBlNmGtwypUUvi4KrKRPzx1cSgVTN0Xocj4fC5N8Rj3tOqOns+EHOX4Rw oy/rebHjQyv1cRr6FyGhRuz24hPv8mAGr/iF0cMphAsujaGKyAo+tA05K3nI0fdoeCx2wdEs vo8jIeeZVii07b3K9+VdJQmerVKJyMfQT6gLkyuassY/5aXlglNxAgMBAAGjggGHMIIBgzAO BgNVHQ8BAf8EBAMCBaAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYm aHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wHQYDVR0RBBYwFIESZ3Ji YXJ0bGVAY2lzY28uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3Nw ZXJzb25hbHNpZ24xZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDov L3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24xZzIuY3J0MB0G A1UdDgQWBBRBHvZ1Aur9AFGMEId10iH6yeUX3jAfBgNVHSMEGDAWgBTsrJjMJ3KTz1YyzSPH nY1FhfQiAzANBgkqhkiG9w0BAQUFAAOCAQEAdhq5YZv5ZCu0/HdQF1S3f+quesVc39HKv+Fe 2rmKuJcxfGOFZGpKhJDa1+sFeN/T+e2e6UJ0Yy90GLqi5U1fioD3XRhsFiVOh7CbJQESF2Xx U1bhdutZFh6Ythe28iRPY6HQjJ/7ke5IQBWvLnAbCIzgy0GgZB9Vj+a2z6bzmfR6KAuLaMqM vahvJ0w+DeHMEOVnVzCdZzHMaEOXZHw/uZj5/hGvkp2C0rH/LhGunfAPX12WhVQSsgxWJhaF 8D49Ymrt7PWBsLokx06/15XwY2ogBmfLmeN/WhMy5HUiLn3EnzwF+RK2MStCDpP5AWzdnrTR tM43+AJrHwoI7H+C9DCCBBYwggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUA MFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdS b290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcN MTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1z YTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGjx0+LH0uRqeZCHrYQ7KN3QuahfxY8 fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqDlin3HracDqMRgwrknWuFeqxh N2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQBhcaJA2ucABbUVTHDTxi 7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+OhtnAhrgzrsd4oAy qgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7upoxvV09Fsf7h DeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUdIAAw NDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAf BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7un yEtmt9Ia7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDu vg/OZ0gILDFIa9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVU m5V1tW3XuYNg6SbtcDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVg wb/j/kplOa13nshhc8zULVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5ui B8TZ0s327g44Ylc6dgKgYelNn9RLYjNETX8OIJZlr0tFYpcYrDCCA3UwggJdoAMCAQICCwQA AAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJv b3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7m mY3Oo+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsur HExwB6E9CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8G PIhpWypNxadUuGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounI Cjjr8iQTT3NUkxOFOhu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjI GSvRRqpI1mQq14M0/ywqwWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8 /UswDQYJKoZIhvcNAQEFBQADggEBANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16q EUi25Qijs8o9YU3TRgmzPsOg42NVG/K676054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeY BN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8suWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUM HaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRWMZXQZ4mFK/lspl1GnQyqguSZUd1wt9tW PWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY24GzBBzFH6SAbxUgyd4MiAod1mZV 4vxIySkmaeAxggH+MIIB+gIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzIC EGZgT+TGYtW+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQg/STk bGOjEZXFhr7JQ3KHMUG+rjCSKwffcQ8g2jEWgpQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTQxMDEwMTEzMTU4WjANBgkqhkiG9w0BAQEFAASCAQAG7F4W e+V5zRFBulotquzYSmYdCM/21H3tgKced+WCtKDe6bvMnPNd8siCK6C2hhFCT8seibfJI+iO lZKQ0rTNyEUi8KHJI3hgOnEcXEOoPL+xVRhWBmlzsU6WYrbn5xbKQUHpy543kHf2PYGZoohF Tau848AYsVd3Nl+0CiUaS/MWpnUQJ7EGrZILT4IbWKyFqs5WSRijJTf65fnXaFrnQIFUfzZj mR0B8UaV9scmHoh5tTgPjYrpoCti6NFMl4Sh+GuwEVS0GeS0hiJ+0uJcJ8z88MbNY8V7yVkO ySQxcfwnF6w6IQ+dD1aZVjgeNqUTtZfFRs8qrTPZ9v4mJl81 --B_3495789118_36187111-- From nobody Fri Oct 10 11:25:23 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375E41ACD2D for ; Fri, 10 Oct 2014 11:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMaRA9MwmFk1 for ; Fri, 10 Oct 2014 11:25:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 442151ACCEA for ; Fri, 10 Oct 2014 11:25:18 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1C3D72002A; Fri, 10 Oct 2014 14:25:30 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 856A963B40; Fri, 10 Oct 2014 14:25:16 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6C6F963AEC; Fri, 10 Oct 2014 14:25:16 -0400 (EDT) From: Michael Richardson To: "Graham Bartlett \(grbartle\)" In-Reply-To: References: <9612D2B2-7DFE-49F5-8593-3750B781956B@gmail.com> <5431A26C.90307@gmail.com> <5432EE25.7050400@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/w58t3jEuRiOLhfwVX8tyDqIvDdE Cc: ipsec , Yoav Nir Subject: Re: [IPsec] A strategy against DoS/DDoS for IKE responders X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 18:25:20 -0000 --=-=-= Graham Bartlett (grbartle) wrote: > Now the only issue I can see is alluded to in the draft, where a VPN > headend is serving clients with varying resource. So say a botnet > attacks this headend and the puzzle is enabled, you have some clients > with a lot of resource (that require a hard puzzle) and some mobile > devices with minimal (that require an easier puzzle). How do you > identify each? The only way I can think is you must do this once the > device has authenticated itself - else how do you know who they are? I have two observations here. The first is that while the botnet can pull in potentially hundreds of teraflops of computation in order to solve a harder puzzle, it has communication overhead in order to do that; The second observation is that the puzzle has to be trivially parallelizable in order for the botnet (or even the multi-core mobile phone!) to do better than a single CPU. The question is: can we design puzzles and the puzzle parameters such that multiple threads of execution do not benefit a single client system? The second part is, can we design the time limit to solve the puzzle such that there becomes very little budget for multi-processor botnet communication. I suspect that this second part is impossible and/or easily spoofed, as we don't know the actual RTT between client and gateway. (Or rather, any RTT estimation could be spoofed by a botnet to give itself more time) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVDgkjICLcPvd0N1lAQKW+wgAoVwaeD00hqpyMlE/ehSmzB7/pwJHusWB 9qH71smfIqwvbO/qdw1n03ZZdGVUG2ji/2hXcYpZDQA4VttkiUwxG9QzICXrWAX5 JZt8tVgQp3IGr2HxyFYH91B8A5u2qKWjFIYaT8WwISB7FNG2/RqX6AkgiqaNUIbi SAMU+lONS/vENBNfr2VD15N3gHm/HE6Z4RWhnRt9QbLl1UEXLiqGnDzngefZIxGV mQ5/T0Bw/HL+26lKYua4y5M67at95QJUoY/Kvma2JkoEEWuRkiS7HW8fPnsBVaYj A45KDIClFZaWUFyccUMAIeV3vM2mb+zb24fEjMYP7SeUkWD1d1odjA== =e8Iv -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 10 12:58:21 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4581ACF19 for ; Fri, 10 Oct 2014 12:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7Dc1KfdQo3q for ; Fri, 10 Oct 2014 12:58:16 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE7D1ACF15 for ; Fri, 10 Oct 2014 12:58:16 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id n3so3062847wiv.15 for ; Fri, 10 Oct 2014 12:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CLQ+Y+yYWOJwmaMPVqTzB3kDIk0UhLxUlhVSU0K712A=; b=Q/Y19avkJOBUSF0TltB3a47PdBzZXK66LeTEi3kqhNz4PI3YgBSNU2ABfSyHYq8Jym UlHktgG6dS/DxnMAtuTtz+86bBU0V3lTBxo8D6f+vemJRRgDTO9UDex96R/gy2tzeeCh fKMBeOFte097UDH4jqD1YYtXVNG00KCGCsQRyUMGoJjpz2nZpBrNF4db9DU+vjewf8Jo Yc2c9vVPFXoMMwQFd18V6bqyAobVLG0Hly2FbBD7xGehqW+spGpg+MS82Ef+wHo7Au+E QV0L+5DTSx/vf25mw37JS34FfKfmmUsO5WlQKSTe+keeP1HISmtT23ETA3S6qVEBBH4h cW8g== X-Received: by 10.180.9.204 with SMTP id c12mr6867917wib.47.1412971095307; Fri, 10 Oct 2014 12:58:15 -0700 (PDT) Received: from [192.168.1.101] (IGLD-84-228-54-144.inter.net.il. [84.228.54.144]) by mx.google.com with ESMTPSA id u2sm8059427wjz.11.2014.10.10.12.58.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Oct 2014 12:58:14 -0700 (PDT) Content-Type: text/plain; charset=euc-kr Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: Date: Fri, 10 Oct 2014 22:58:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9612D2B2-7DFE-49F5-8593-3750B781956B@gmail.com> <5431A26C.90307@gmail.com> <5432EE25.7050400@gmail.com> To: "Graham Bartlett (grbartle)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/unLt8f4gdwixs04bWgUDM5iIYgs Cc: ipsec Subject: Re: [IPsec] A strategy against DoS/DDoS for IKE responders X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 19:58:18 -0000 Hi, Graham. Thanks for the endorsement, but see below. On Oct 10, 2014, at 2:31 PM, Graham Bartlett (grbartle) = wrote: > Hi Yaron / Yoav >=20 > I'm summarising my thoughts below, I've spoken to a few folk offlist = and > hopefully the following will help my understanding and also theirs. >=20 > So assuming a device is under potential attack by devices using their = own > addresses (botnet or similar), the cookie notification is not going to > give any benefit (as they are using a legitimate IP address), but = Yoav's > puzzle will slow the attack down. The cookie mechanism helps in one way. If my IPsec gateway is up against = an X-node botnet, the cookie mechanism limits the botnet to X unique IP = addresses (or IPv6 prefixes). This in itself doesn=A1=AFt help much, but we can limit the amount of = concurrent half-open SAs that the gateway is willing to store from a = particular IP address or prefix. So if, for example, we hold a half-open = SA for 10 seconds and allow an IPv4 address / IPv6 prefix to have at = most 5 half-open SAs, this limits each node in the botnet to 1 half-open = SA every two seconds, even if their bandwidth is sufficient to create = many more. It also limits the total half-open SAs that they can hold on = the gateway to 5X. The limit mechanism doesn=A1=AFt work without either = cookies or puzzles. Reducing the time an half-open SA is held doesn=A1=AFt really help in = this scenario, because I=A1=AFm assuming that the attackers have enough = bandwidth. So if we reduce the hold time to 1 second, they should be = able to create 5 half-open SAs per second. This is where puzzles come = in. They can reduce the rate that these attacking nodes can create new = half-open SAs. Yoav From nobody Fri Oct 10 13:00:32 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5181A702F for ; Fri, 10 Oct 2014 13:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPPlrIbeYLaC for ; Fri, 10 Oct 2014 13:00:27 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F1361ACEFE for ; Fri, 10 Oct 2014 13:00:26 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id fb4so3077385wid.12 for ; Fri, 10 Oct 2014 13:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FyITljMCp2kltHA8tcjGi+giV6ovjlcQ68Yq/6iNlUQ=; b=Ku10EYRNG/rQFuf4teSn6kUdj6lbvdltoJsA9KlGgvaNx/3U7g9uk+Z4+nkmsnfrGD qddK8H1KayRKGrM8PTw13cee1BGSZ1HzOHiB4EMTHzzIc0U9Kiw/WdhlUfkDj3lFLwVh FUgGEpkuA2G7d4gazAxOpi4imFQ7aYJIaskPeL2hXx4dNH5gFqHqJn+dbkEo0/djPYCs t4AqJ5oTXfIrgREqolX8hxrnHI+tIpo7jCcz3fQN/PTKObKNywkCKO9CfjZDIPgA0TaR PEMFKgqAbOerqDWqTUnlLfJVa3PSC1U6muLh7ISyQ/Zg9aXYbqtxrwxnucL6KKMaW3IT BzeA== X-Received: by 10.181.13.73 with SMTP id ew9mr6902610wid.56.1412971225818; Fri, 10 Oct 2014 13:00:25 -0700 (PDT) Received: from [192.168.1.101] (IGLD-84-228-54-144.inter.net.il. [84.228.54.144]) by mx.google.com with ESMTPSA id yr10sm8031958wjc.38.2014.10.10.13.00.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Oct 2014 13:00:25 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <29235.1412965516@sandelman.ca> Date: Fri, 10 Oct 2014 23:00:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2947DDB6-B71B-4FEB-8202-2EC1C69AC8DE@gmail.com> References: <9612D2B2-7DFE-49F5-8593-3750B781956B@gmail.com> <5431A26C.90307@gmail.com> <5432EE25.7050400@gmail.com> <29235.1412965516@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/sTh-XuyzBps51edTpPM8X-4HzAg Cc: ipsec , "Graham Bartlett \(grbartle\)" Subject: Re: [IPsec] A strategy against DoS/DDoS for IKE responders X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 20:00:31 -0000 On Oct 10, 2014, at 9:25 PM, Michael Richardson = wrote: >=20 > Graham Bartlett (grbartle) wrote: >> Now the only issue I can see is alluded to in the draft, where a VPN >> headend is serving clients with varying resource. So say a botnet >> attacks this headend and the puzzle is enabled, you have some clients >> with a lot of resource (that require a hard puzzle) and some mobile >> devices with minimal (that require an easier puzzle). How do you >> identify each? The only way I can think is you must do this once the >> device has authenticated itself - else how do you know who they are? >=20 > I have two observations here. >=20 > The first is that while the botnet can pull in potentially hundreds of > teraflops of computation in order to solve a harder puzzle, it has > communication overhead in order to do that; >=20 > The second observation is that the puzzle has to be trivially = parallelizable > in order for the botnet (or even the multi-core mobile phone!) to do = better > than a single CPU. I don=92t think this is the best strategy for the botnet. Rather than = pool all their resources to solve a single puzzle (bitcoin-style), = wouldn=92t it be better for each node to act like a legitimate client = and solve its own puzzle in however long it takes? Yoav From nobody Fri Oct 10 13:33:30 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A4A1AD055 for ; Fri, 10 Oct 2014 13:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 179nKCBH9a69 for ; Fri, 10 Oct 2014 13:33:27 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F571ACFFD for ; Fri, 10 Oct 2014 13:33:26 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x12so4812527wgg.20 for ; Fri, 10 Oct 2014 13:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3sqYeV6HdU5dJc9RRhh5y+cgcpJXwphV3G+7GB3fwx8=; b=UzM/hVkeGa83czKbNX8AkKHdWKC/wBUHiOn0fh22uTLsWDruKMBraamrXwXxCIZh6H E1t44xe6b4relEBf2d7MO0u2dmfM7uOgQtmpeXAnRPId+HNUpInS/VOrXqRRS7SaJtEI FAofMvJA+z/+gGlaWHsPOaHaRVvIzEJGnMFYEIjURyvgELxIYVSN4uoSWgfi5h9vkUpN MlXvx3hgqQnL8vQDNWyuHyALJlApfbXd1ZDcs6hh+C0KzyeVGnMeHMKUOe4/YhZxQYdW ywsVJy1ROBpciZDDMvv8bQzZVzQ5kUc1SOaCF0ur/O6YvXaVWXTdl4vSjtBImSHp5mZo 9Qbw== X-Received: by 10.194.249.164 with SMTP id yv4mr7335784wjc.34.1412973205709; Fri, 10 Oct 2014 13:33:25 -0700 (PDT) Received: from [10.0.0.6] (bzq-79-183-174-9.red.bezeqint.net. [79.183.174.9]) by mx.google.com with ESMTPSA id i5sm9348293wjz.0.2014.10.10.13.33.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Oct 2014 13:33:25 -0700 (PDT) Message-ID: <54384292.80800@gmail.com> Date: Fri, 10 Oct 2014 23:33:22 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Yoav Nir , Michael Richardson References: <9612D2B2-7DFE-49F5-8593-3750B781956B@gmail.com> <5431A26C.90307@gmail.com> <5432EE25.7050400@gmail.com> <29235.1412965516@sandelman.ca> <2947DDB6-B71B-4FEB-8202-2EC1C69AC8DE@gmail.com> In-Reply-To: <2947DDB6-B71B-4FEB-8202-2EC1C69AC8DE@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/mIHJJA8-a7nopqzVEr-qDvJRBI0 Cc: ipsec , "Graham Bartlett \(grbartle\)" Subject: Re: [IPsec] A strategy against DoS/DDoS for IKE responders X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 20:33:28 -0000 > > I don’t think this is the best strategy for the botnet. Rather than pool all their resources to solve a single puzzle (bitcoin-style), wouldn’t it be better for each node to act like a legitimate client and solve its own puzzle in however long it takes? > > Yoav > Yoav, I don't see your point. Suppose I have a 1,000 node botnet, and only 100 of them are currently busy with a DoS attack on Yoav's favorite gateway. The other 900 nodes are idling, waiting for the next batch of spam to arrive. Why not use them to compute hashes so that I can create 10X as many half-open SAs? Thanks, Yaron From nobody Sat Oct 11 14:39:16 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D282D1A87DF for ; Sat, 11 Oct 2014 14:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHkraQuyyY4H for ; Sat, 11 Oct 2014 14:39:13 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2025F1A87DB for ; Sat, 11 Oct 2014 14:39:13 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6FF052002F; Sat, 11 Oct 2014 17:39:29 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E821E63B40; Sat, 11 Oct 2014 17:39:11 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CD98863AEC; Sat, 11 Oct 2014 17:39:11 -0400 (EDT) From: Michael Richardson To: Yoav Nir In-Reply-To: <2947DDB6-B71B-4FEB-8202-2EC1C69AC8DE@gmail.com> References: <9612D2B2-7DFE-49F5-8593-3750B781956B@gmail.com> <5431A26C.90307@gmail.com> <5432EE25.7050400@gmail.com> <29235.1412965516@sandelman.ca> <2947DDB6-B71B-4FEB-8202-2EC1C69AC8DE@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/8V7LUXS3gMMTj80qIBJGkosLCRw Cc: ipsec , "Graham Bartlett \(grbartle\)" Subject: Re: [IPsec] A strategy against DoS/DDoS for IKE responders X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 21:39:15 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: >> Graham Bartlett (grbartle) wrote: >>> Now the only issue I can see is alluded to in the draft, where a VPN >>> headend is serving clients with varying resource. So say a botnet >>> attacks this headend and the puzzle is enabled, you have some clien= ts >>> with a lot of resource (that require a hard puzzle) and some mobile >>> devices with minimal (that require an easier puzzle). How do you >>> identify each? The only way I can think is you must do this once the >>> device has authenticated itself - else how do you know who they are? >>=20 >> I have two observations here. >>=20 >> The first is that while the botnet can pull in potentially hundreds = of >> teraflops of computation in order to solve a harder puzzle, it has >> communication overhead in order to do that; >>=20 >> The second observation is that the puzzle has to be trivially >> parallelizable in order for the botnet (or even the multi-core mobile >> phone!) to do better than a single CPU. > I don=E2=80=99t think this is the best strategy for the botnet. Rathe= r than > pool all their resources to solve a single puzzle (bitcoin-style), > wouldn=E2=80=99t it be better for each node to act like a legitimate = client and > solve its own puzzle in however long it takes? I agree that this might be a better strategy for the botnet, and I think that we can more easily defend against. So the goal here is to make sure that we select puzzles which drive the botnet towards this. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVDmjfICLcPvd0N1lAQLJQQf+LFqyQE7EmD8/eeEsqnxwgrr6LcHqNC60 ED4K0d8+WABF5sOBeFDcF1I5uRqbQllkRj8cjaO579yZJ4+wQZoX2OWcVCM4lalG tmaOIGvrA/nr77VJxKfDLk20AHKFsgn1EIFURCs774Ssqm6z6D82U14n/ygcQrjd BIXjNs8blftz9fHeX/TSjLD+6IUG09YlZc95tMEdq9cDQmytrI/YWoE65uXnmt5B C7vtWzn4jEYh4SVBcDHJkYLPAu55RJBtzoqagVCN36h61eLC07PJnBYCGcG8+uaS KikBtk6yDKqPxiGB4EeuDQv+XacfayM9fvW6Wm0XJiHdYyBHZxOIhQ== =FH6E -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Oct 12 15:04:28 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89791A910E for ; Sun, 12 Oct 2014 15:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcK8x8ylb86l for ; Sun, 12 Oct 2014 15:04:25 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25581A910B for ; Sun, 12 Oct 2014 15:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8481; q=dns/txt; s=iport; t=1413151465; x=1414361065; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=O2Hj8xSC5RSI6b2Rvc1IQuNLqNeS0uuIg0gaqS/vd9s=; b=KZHv47g0K7F+Z7svwjTl8KkGVI1AzsQrtnpGl2XVT+ulBfR88NP7/+9C Tm/BazVxUeUNWFd3MTYHpvyOl3hYokcS1uGF0l4C32uKUdPPUPoteK4pE bQT4Ex3bexbzPGVB/199shfel1lUzhbvrKPjTQBQS/6ggqDJ7E6fdb9fV Q=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAHL5OlStJV2U/2dsb2JhbABbgmsjgSsE0kwCgQYWAX2EAwEBBHkQAgEIDgouAh8RJQIEDgUOiBwDEQG8Hg2GaQEBAQEBAQEBAQEBAQEBAQEBAQEBAReCYYsygVs8GweESwWLIIZZggyBT4VmghGBLo4PglaDfoN3bIEHQYECAQEB X-IronPort-AV: E=Sophos;i="5.04,706,1406592000"; d="p7s'?scan'208";a="86297874" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP; 12 Oct 2014 22:04:24 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9CM4NtB018313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 Oct 2014 22:04:23 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Sun, 12 Oct 2014 17:04:23 -0500 From: "Graham Bartlett (grbartle)" To: Yoav Nir Thread-Topic: [IPsec] A strategy against DoS/DDoS for IKE responders Thread-Index: AQHP4IbF+Xf2zTD2ikCTmGddD9T/C5wiP6oAgAAHRYCAANx7gIAAp7KAgAXUBQCAAHyvgIADWKuA Date: Sun, 12 Oct 2014 22:04:22 +0000 Message-ID: References: <9612D2B2-7DFE-49F5-8593-3750B781956B@gmail.com> <5431A26C.90307@gmail.com> <5432EE25.7050400@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.55.146.100] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3495999861_41449898" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/IJguSJCN939IXCcBbhXXvg97McQ Cc: ipsec Subject: Re: [IPsec] A strategy against DoS/DDoS for IKE responders X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 22:04:27 -0000 --B_3495999861_41449898 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Yoav Thanks for the explanation, just for my understanding, why does this rate-limiting have to (strictly) rely on the cookie (or puzzle) notification? Is it more of the case that it guarantees that the attacker is the attacker (prevents blind-spoofing) and as you say limits the attacker to using their own IP address? So say our bot would send 5 requests a second and always get to IKE_AUTH and transmit a random value attempting to authenticate, it would never leave any half open SAs. I presume enabling the cookie notification will prevent the bot attempting to masquerade as another legitimate address at the same time (where your rate-limiting would help prevent a DOS condition). As the attacker would never leave any half-open SA's (as they get to IKE_AUTH and then Authentication would fail), so strictly speaking the cookie notification might never be employed (if it's enabled to be activated when half open SA's are detected) and you could (and should) rate-limit without enabling cookies. I'm not knocking the cookie-notification (I'm all for it), but I think that rate-limiting should occur even if the headend isn't detecting a large number of half-open SA's. cheers On 10/10/2014 20:58, "Yoav Nir" wrote: >Hi, Graham. > >Thanks for the endorsement, but see below. > >On Oct 10, 2014, at 2:31 PM, Graham Bartlett (grbartle) > wrote: > >> Hi Yaron / Yoav >>=20 >> I'm summarising my thoughts below, I've spoken to a few folk offlist and >> hopefully the following will help my understanding and also theirs. >>=20 >> So assuming a device is under potential attack by devices using their >>own >> addresses (botnet or similar), the cookie notification is not going to >> give any benefit (as they are using a legitimate IP address), but Yoav's >> puzzle will slow the attack down. > >The cookie mechanism helps in one way. If my IPsec gateway is up against >an X-node botnet, the cookie mechanism limits the botnet to X unique IP >addresses (or IPv6 prefixes). > >This in itself doesn=B9t help much, but we can limit the amount of >concurrent half-open SAs that the gateway is willing to store from a >particular IP address or prefix. So if, for example, we hold a half-open >SA for 10 seconds and allow an IPv4 address / IPv6 prefix to have at most >5 half-open SAs, this limits each node in the botnet to 1 half-open SA >every two seconds, even if their bandwidth is sufficient to create many >more. It also limits the total half-open SAs that they can hold on the >gateway to 5X. The limit mechanism doesn=B9t work without either cookies or >puzzles. > >Reducing the time an half-open SA is held doesn=B9t really help in this >scenario, because I=B9m assuming that the attackers have enough bandwidth. >So if we reduce the hold time to 1 second, they should be able to create >5 half-open SAs per second. This is where puzzles come in. They can >reduce the rate that these attacking nodes can create new half-open SAs. > >Yoav > --B_3495999861_41449898 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIOeAYJKoZIhvcNAQcCoIIOaTCCDmUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggw+MIIEpzCCA4+gAwIBAgIQZmBP5MZi1b5ckUheWh5wbTANBgkqhkiG9w0BAQUFADBU MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv YmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMB4XDTE0MDEyNTIyNDE0OFoXDTE2MDYw MzExMDA1OFowQDEbMBkGA1UEAwwSZ3JiYXJ0bGVAY2lzY28uY29tMSEwHwYJKoZIhvcNAQkB FhJncmJhcnRsZUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCq YhYxolKrFoPfXuZTQdAiQVFg14EvWwIEMyXxhfH2RiwOSJRSsUVmTNYG8HdeSf0JdzjAMh9p ODgxLC90Q1nbLyBqmEAKElWTasAnATKBCD7aLhce+25cznTT4FDpJsvvU2lZFPWXSLQm3bNR +mEDP6pd8zR1ItOKBlNmGtwypUUvi4KrKRPzx1cSgVTN0Xocj4fC5N8Rj3tOqOns+EHOX4Rw oy/rebHjQyv1cRr6FyGhRuz24hPv8mAGr/iF0cMphAsujaGKyAo+tA05K3nI0fdoeCx2wdEs vo8jIeeZVii07b3K9+VdJQmerVKJyMfQT6gLkyuassY/5aXlglNxAgMBAAGjggGHMIIBgzAO BgNVHQ8BAf8EBAMCBaAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYm aHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wHQYDVR0RBBYwFIESZ3Ji YXJ0bGVAY2lzY28uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3Nw ZXJzb25hbHNpZ24xZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDov L3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24xZzIuY3J0MB0G A1UdDgQWBBRBHvZ1Aur9AFGMEId10iH6yeUX3jAfBgNVHSMEGDAWgBTsrJjMJ3KTz1YyzSPH nY1FhfQiAzANBgkqhkiG9w0BAQUFAAOCAQEAdhq5YZv5ZCu0/HdQF1S3f+quesVc39HKv+Fe 2rmKuJcxfGOFZGpKhJDa1+sFeN/T+e2e6UJ0Yy90GLqi5U1fioD3XRhsFiVOh7CbJQESF2Xx U1bhdutZFh6Ythe28iRPY6HQjJ/7ke5IQBWvLnAbCIzgy0GgZB9Vj+a2z6bzmfR6KAuLaMqM vahvJ0w+DeHMEOVnVzCdZzHMaEOXZHw/uZj5/hGvkp2C0rH/LhGunfAPX12WhVQSsgxWJhaF 8D49Ymrt7PWBsLokx06/15XwY2ogBmfLmeN/WhMy5HUiLn3EnzwF+RK2MStCDpP5AWzdnrTR tM43+AJrHwoI7H+C9DCCBBYwggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUA MFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdS b290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcN MTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1z YTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGjx0+LH0uRqeZCHrYQ7KN3QuahfxY8 fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqDlin3HracDqMRgwrknWuFeqxh N2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQBhcaJA2ucABbUVTHDTxi 7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+OhtnAhrgzrsd4oAy qgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7upoxvV09Fsf7h DeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUdIAAw NDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAf BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7un yEtmt9Ia7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDu vg/OZ0gILDFIa9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVU m5V1tW3XuYNg6SbtcDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVg wb/j/kplOa13nshhc8zULVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5ui B8TZ0s327g44Ylc6dgKgYelNn9RLYjNETX8OIJZlr0tFYpcYrDCCA3UwggJdoAMCAQICCwQA AAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJv b3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7m mY3Oo+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsur HExwB6E9CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8G PIhpWypNxadUuGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounI Cjjr8iQTT3NUkxOFOhu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjI GSvRRqpI1mQq14M0/ywqwWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8 /UswDQYJKoZIhvcNAQEFBQADggEBANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16q EUi25Qijs8o9YU3TRgmzPsOg42NVG/K676054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeY BN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8suWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUM HaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRWMZXQZ4mFK/lspl1GnQyqguSZUd1wt9tW PWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY24GzBBzFH6SAbxUgyd4MiAod1mZV 4vxIySkmaeAxggH+MIIB+gIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzIC EGZgT+TGYtW+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgsRjq fGXIHNO6P4UBFc2CcGmB5v3y57Tx/VkXLlENhMEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTQxMDEyMjIwNDIxWjANBgkqhkiG9w0BAQEFAASCAQCHn3rG gqyc29yjmkgxhubOHb3zc1RMwFEzQ8+R4DGR4YoGk+8gaFsEBifHF1wAMhlR25MDDBXdiXq5 cKYqVfBTILFzVXck+OH7BiFvs15UYa+ldwPhvgBYFw82qmAqAq8LoGJgx27CzQGeAVTkNrBJ sd2/W1EPFuKPnQLZuInXHOsL1rIb1BypoAsvYbUYFtOlCkyyWK/uPr/YN4JHAw3Is6Cgogt2 MQ3QR8w/Gh7pJ7bVXurB6lpokVEIl6TCiW3qnuLGv1ysoT1H8GDp5rfo5j7vHHxOsnJlPp5L I2IdKubVr/jGczKg02ISYY0fkud/1kU1eiN7WvJD7lIKVH1h --B_3495999861_41449898-- From nobody Mon Oct 13 00:09:11 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7291A88D3 for ; Mon, 13 Oct 2014 00:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tDtqmrUa5ij for ; Mon, 13 Oct 2014 00:09:07 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 663C91A88C6 for ; Mon, 13 Oct 2014 00:09:07 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id d1so6543380wiv.2 for ; Mon, 13 Oct 2014 00:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=uiQCyjGMmH3qmafdo04u233VPdISsN3+qfVcAGSn1C4=; b=iZIoWFNnao37D3IU9FRiDOf7T+WijwtFfLHewwH0atsSNyjlTQTsSS0+Q6T8/956h4 PZkPZbHXp0R1+NDZZjBRj091CbYmq4zcxcl8uI+fr/20kbLTv9rcy/l8QuDIp7yWUvrY xbP9VnjHPkQHwdsWrJ/0opTzJnYs5nXIlKy5FzPFPKTDyPsl2l7MYgEDlPItmHmj2znN JNjPn4vQ46+HeOzxQQ2ms/6qqpvXnWuyfjVyIWTZzKBftoLWgawuP1wbU5Ewnhh5Mg8u U5JhRQV2wRyWFkKUmeAiYISzbGeCmuwfFsFiBwHklNtI8fNi2WKQNcYY6Bo02siGiMUT wqpA== X-Received: by 10.194.88.99 with SMTP id bf3mr19205143wjb.16.1413184146033; Mon, 13 Oct 2014 00:09:06 -0700 (PDT) Received: from [172.24.248.64] ([194.29.32.131]) by mx.google.com with ESMTPSA id h4sm15589453wjb.9.2014.10.13.00.09.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Oct 2014 00:09:05 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1BA196B2-EB6A-43CD-8A22-FC7EC93701F9" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: Date: Mon, 13 Oct 2014 10:09:01 +0300 Message-Id: <460B7970-86E5-4256-8ED6-31FEB67651AE@gmail.com> References: <9612D2B2-7DFE-49F5-8593-3750B781956B@gmail.com> <5431A26C.90307@gmail.com> <5432EE25.7050400@gmail.com> To: "Graham Bartlett (grbartle)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/SzvZmg4u1J3tlmy2d7D7ooW363I Cc: ipsec Subject: Re: [IPsec] A strategy against DoS/DDoS for IKE responders X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 07:09:10 -0000 --Apple-Mail=_1BA196B2-EB6A-43CD-8A22-FC7EC93701F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 13, 2014, at 1:04 AM, Graham Bartlett (grbartle) = wrote: > Hi Yoav >=20 > Thanks for the explanation, just for my understanding, why does this > rate-limiting have to (strictly) rely on the cookie (or puzzle) > notification? Is it more of the case that it guarantees that the = attacker > is the attacker (prevents blind-spoofing) and as you say limits the > attacker to using their own IP address? I think you got it. Without something that guarantees return routability = such as the cookie or the puzzle, an attacker can sent IKE_INIT = requests, one from each and every Internet address, quickly exhausting = the half-open SA database. It doesn=92t help to rate-limit if the = attacker has a nearly-infinite supply of source addresses. At least the = cookies limit the attacker to the actual size of her botnet. > So say our bot would send 5 requests a second and always get to = IKE_AUTH > and transmit a random value attempting to authenticate, it would never > leave any half open SAs. I presume enabling the cookie notification = will > prevent the bot attempting to masquerade as another legitimate address = at > the same time (where your rate-limiting would help prevent a DOS > condition). As the attacker would never leave any half-open SA's (as = they > get to IKE_AUTH and then Authentication would fail), so strictly = speaking > the cookie notification might never be employed (if it's enabled to be > activated when half open SA's are detected) and you could (and should) > rate-limit without enabling cookies. The cookie mechanism prevents the blind spoofing, so it=92s forcing the = attacker to this kind of attack, where rate-limiting is helping. > I'm not knocking the cookie-notification (I'm all for it), but I think > that rate-limiting should occur even if the headend isn't detecting a > large number of half-open SA=92s. Sure. But as long as we=92re not preventing spoofed requests, the = attacker can still use the other strategy. Yoav= --Apple-Mail=_1BA196B2-EB6A-43CD-8A22-FC7EC93701F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Oct 13, 2014, at 1:04 AM, Graham = Bartlett (grbartle) <grbartle@cisco.com> = wrote:

Hi Yoav

Thanks for the = explanation, just for my understanding, why does this
rate-limiting = have to (strictly) rely on the cookie (or puzzle)
notification? Is it = more of the case that it guarantees that the attacker
is the attacker = (prevents blind-spoofing) and as you say limits the
attacker to using = their own IP address?

I think you = got it. Without something that guarantees return routability such as the = cookie or the puzzle, an attacker can sent IKE_INIT requests, one from = each and every Internet address, quickly exhausting the half-open SA = database. It doesn=92t help to rate-limit if the attacker has a = nearly-infinite supply of source addresses. At least the cookies limit = the attacker to the actual size of her = botnet.

So say our bot would send 5 requests a = second and always get to IKE_AUTH
and transmit a random value = attempting to authenticate, it would never
leave any half open SAs. I = presume enabling the cookie notification will
prevent the bot = attempting to masquerade as another legitimate address at
the same = time (where your rate-limiting would help prevent a DOS
condition). = As the attacker would never leave any half-open SA's (as they
get to = IKE_AUTH and then Authentication would fail), so strictly = speaking
the cookie notification might never be employed (if it's = enabled to be
activated when half open SA's are detected) and you = could (and should)
rate-limit without enabling = cookies.

The cookie mechanism = prevents the blind spoofing, so it=92s forcing the attacker to this kind = of attack, where rate-limiting is helping.

I'm not knocking the = cookie-notification (I'm all for it), but I think
that rate-limiting = should occur even if the headend isn't detecting a
large number of = half-open SA=92s.

Sure. But as long = as we=92re not preventing spoofed requests, the attacker can still use = the other strategy.

Yoav
= --Apple-Mail=_1BA196B2-EB6A-43CD-8A22-FC7EC93701F9-- From nobody Mon Oct 13 07:14:29 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C45A1A000A for ; Mon, 13 Oct 2014 07:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.793 X-Spam-Level: X-Spam-Status: No, score=0.793 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9oKOe6xhACF for ; Mon, 13 Oct 2014 07:14:23 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D651A9090 for ; Mon, 13 Oct 2014 07:14:22 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s9DEEJwT008938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Oct 2014 17:14:19 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s9DEEHiB027713; Mon, 13 Oct 2014 17:14:17 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21563.56889.150972.806712@fireball.kivinen.iki.fi> Date: Mon, 13 Oct 2014 17:14:17 +0300 From: Tero Kivinen To: Michael Richardson In-Reply-To: <22982.1412098993@sandelman.ca> References: <541F2C84.7050805@gmail.com> <359A7BBE-22E7-4BDF-8435-C06860701E9B@vpnc.org> <13992.1411997208@sandelman.ca> <21546.35173.105704.345146@fireball.kivinen.iki.fi> <22982.1412098993@sandelman.ca> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 19 min X-Total-Time: 20 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/6gt7Pbge9laaPw0UpMN3LxKcsqo Cc: ipsec , Paul Hoffman Subject: Re: [IPsec] Call for adoption: Client Puzzles X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:14:27 -0000 Michael Richardson writes: > > Tero Kivinen wrote: > > 3) Client can also be smartphone, i.e. device which have quite a lot of > > CPU power and/or memory, but does not want to use it as it would > > increase the power usage so much that the battery life will be > > shortened. > > Except that client being smartphone/etc. is behind NAT44, and along with > ten thousand other smartphones, all have the same IP address... this matters > because that scenario is probably indistinguishable from: Good, as then we get rid of the NAT44... And then I woke up... Anyways, I would expect big CGNs to try to spread the clients over multiple different IP-addresses, instead of putting them all to single IP-address. There are lots of other things that gets banned by IP-address, so this kind of spreading is something they should do anyways. For example forums, games etc quite often ban specific IP-addresses for a while after certain bad events. I know that slashdot once banned our company IP-block because some people fetched their mainpage too often... > > 7) Botnets have huge amount of CPU power and lots of memory, but still > > limited number of distinguished IPv4-addresses or IPv6-prefixes (it > > might be millions, but most likely around thousands or tens of > > thousands IP-addresses). > > a situation where there is an enterprise of compromised systems behind > the enterprise firewall. (University lab networks come to mind...) In which case it is good thing that people start complaining to the helpdesk, which will start investigating the issue, and they find out they have botnet machines inside the network... I.e. it is almost impossible to protect against the attacks where the attacker is inside your own machine or located very close to you... > Further, the botnets don't need to present thousands of distinguished IPv4 > addresses, they can present a small number of attack nodes, spreading the > work across the botnet? You assume that the cost of puzzle would be meaningful for them so it would be useful to spread the work. I assume it will not be. Most likely the puzzles need to be something that the small devices can also solve, which means they are not that expensive for the real desktop machines. On the other hand if sending a single packet costs 1 unit of CPU power, and attacker has 10000 units of CPU power in his machine, that means he can send 10,000 packets per second out. If the puzzle requires 100 units of power, that means we reduced the attack speed down to 100 packets per second. For the SGW verification will most likely take something like 1 unit, so it can withstand attacks of 100 machines with same cpu power as it has. If the small device have 10 units of CPU power per second, that means it will take 10 seconds to solve the puzzle, but as I said the small device will most likely be able to cope with such long delay for connection, and it can still connect. Spreading the attacks to 1000 other machines does not really help as the network overhead to distribute the puzzles will get more expensive than solving the actual puzzle... Also the attacker will need lots of different IP-addresses as those it has used before will get blacklisted. There is also ways of using constant memory to store this kind of blacklists (http://en.wikipedia.org/wiki/Bloom_filter) which are already used for the graylisting and such mail servers to filter out requests by IP-addresses. > So this tells me that we are looking for puzzles which are *not* > parallelizable. I know little about this kind of stuff... If the puzzle is very expensive then yes, but if it just to raise the relative cost of the attacker to higher, then they most likely will not have reason to distribute it. Also the amount of unique source IP-addresses is much bigger problems to them than CPU power... > I suspect, however, that the simplest machines to DDoS will be the > smallest gateways. Of course. On the other hand the attackers have less interest to attack those. It does not really get to news when they tell that they DDoSed some persons home gateway. Most likely even if they tell that they DDoSed 10000 home gateways is not really news... Most of the users would not even notice this, they would just blame their ISP or vendor as the device is slow, and then they would reboot it :-) I would expect the attack to go against big enterprices, for example the power or phone companies. -- kivinen@iki.fi From nobody Mon Oct 13 07:22:29 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406281A0060 for ; Mon, 13 Oct 2014 07:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpfOlQvE6sXB for ; Mon, 13 Oct 2014 07:22:24 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA871A0059 for ; Mon, 13 Oct 2014 07:22:23 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s9DEMHjo006828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Oct 2014 17:22:17 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s9DEMGuX005852; Mon, 13 Oct 2014 17:22:16 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <21563.57368.482523.216974@fireball.kivinen.iki.fi> Date: Mon, 13 Oct 2014 17:22:16 +0300 From: Tero Kivinen To: Nico Williams In-Reply-To: <20141006012059.GE14969@localhost> References: <9612D2B2-7DFE-49F5-8593-3750B781956B@gmail.com> <5431A26C.90307@gmail.com> <20141006012059.GE14969@localhost> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 5 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/8Cy7lFM5iY-CI0kiM1CAmZF9llw Cc: ipsec , Yoav Nir Subject: Re: [IPsec] A strategy against DoS/DDoS for IKE responders X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:22:25 -0000 Nico Williams writes: > On Sun, Oct 05, 2014 at 11:22:29PM +0300, Yoav Nir wrote: > > Now the responder has two options: > > (1) delete the entry in the half-open SA database, or > > (2) store the derived key, and keep the half-open SA another 9.5 s= econds. > >=20 > > (2) has the disadvantage that the attacker can keep sending more ju= nk packets and get the responder to attempt to decrypt all of them. > > (1) has the disadvantage that an attacker can inject a junk IKE=5FA= UTH request by just copying the IKE SPIs from the IKE=5FINIT response, = which will prevent the responder from processing the real initiator=E2=80= =99s IKE=5FAUTH request. > >=20 > > So I=E2=80=99m not sure which is worse. >=20 > Split the difference. Shorten the amount of time you keep the half-o= pen > SA around. After we have received first IKE=5FAUTH message, we have already done all the expensive calculations already. I.e we have done the other half of Diffie-Hellman, and there is no point of throwing away that context, even if we get some packets which fail to decrypt. Note, that throwing away packets after this is just one MAC and compare, thus it is very fast compared to the Diffie-Hellman setup.=20 > The amount of time to keep a half-open SA/connection/state around > should be dynamic: based on something like N standard deviations from= > the average time to complete a handshake when not under (D)DoS attack= =2E >=20 > 10 seconds is a lot!! No it is not. If you are using EAP, it might be that there is some userinteraction during the IKE=5FAUTH time. There should not be anythin= g for the first packet, but for later ones there might be. I.e. the pre-shared key needed to send the first IKE=5FAUTH packet should already be asked from user before even sending first IKE=5FSA=5FINIT... Also for small devices might take 10 seconds to actually do the other half of the Diffie-Hellman... I would expect that most timeouts during this phase are in order of minutes... Especially as there might be crappy networks between. --=20 kivinen@iki.fi From jah@open.ch Sun Oct 12 17:40:15 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5E11A7017 for ; Sun, 12 Oct 2014 17:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 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.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2KWNVQI9SFA for ; Sun, 12 Oct 2014 17:40:14 -0700 (PDT) Received: from mx2.open.ch (mx2.open.ch [213.156.239.108]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C39181A6FAD for ; Sun, 12 Oct 2014 17:40:13 -0700 (PDT) Received: from mx2.open.ch (localhost [127.0.0.1]) by mx2.open.ch (Mission Control Email Shield, 616) with SMTP id 3jGLdR1DY6zjfw for ; Mon, 13 Oct 2014 02:40:11 +0200 (MEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open.ch; s=mail_201403; t=1413160811; bh=LHPuTFBsQePouaeMusXKowspY07s9K3glnsVM2j4xIg=; h=Date:From:To:CC:Subject:From; b=H6h3c0z4e1PLpZB6QWSJN5MpJj/fLH8EUdwQMZXy+WxwlyIVPRwsPxO54HoV8lVmq mgPm2Q3tQP2IuUzEaZsIVMZuDqxbcmJ9pxA59YLLNrMsJg51bugTXEp1Cq1cIzjKdv TfNgYjJpRNrnzxwrtKB3gqrtTRda+lI+WaxbyvMQ= Message-ID: <7452_1413160811_543B1F6B_7452_6802_1_543B1F65.3090206@open.ch> Date: Mon, 13 Oct 2014 11:40:05 +1100 From: James Hulka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/xRY3dQSVK5vNkgbfQMGtn0MTjj0 X-Mailman-Approved-At: Mon, 13 Oct 2014 08:02:05 -0700 Cc: Roman Hoog Antink , Stefan Keller Subject: [IPsec] IKEv2 protocol race condition for auto start X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 00:41:54 -0000 Dear IPsec Working Group, there is a race condition in the current IKEv2 protocol when 2 site peers= are configured to automatically establish a IPsec tunnel. Both peers can successfully initiate the IKE_SAs which results in each pe= er having 2 options available for further communication. If each peer sel= ects a different IKE_SA, communication is blocked. We reported this as an issue in the StrongSwan mailing list in 2013 (http= s://www.mail-archive.com/dev@lists.strongswan.org/msg00731.html) and alth= ough they have a mechanism to prevent this, it does not catch ALL cases. = They are very strict about being RFC compliant (which is good) and theref= ore could not correct the issue in their IPsec daemon. Currently we handle such cases with a script that is called by a hook whe= n an IPsec tunnel is established. In this script we check for multiple IK= E_SAs for a given tunnel and if found remove the IKE_SA with the lower SA= ID. It would be good if such a case could be handled in the IKE protocol itse= lf as in the case of site to site IPsec it is often a requirement that a = tunnel can be automatically re established after a long connectivity outa= ge. In a large mesh topology this gets very complicated to keep track of = which host should automatically reconnect and which host should passively= wait for a connection on a per tunnel basis. Best Regards, James Hulka james hulka security engineer open systems ag raeffelstrasse 29 ch-8045 zurich t: +41 58 100 10 10 f: +41 58 100 10 11 jah@open.ch http://www.open.ch From nobody Mon Oct 13 08:26:04 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510301A0393 for ; Mon, 13 Oct 2014 08:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA4oGhtcxjbh for ; Mon, 13 Oct 2014 08:25:59 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EA3C1A0329 for ; Mon, 13 Oct 2014 08:25:58 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s9DFPtwY029895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Oct 2014 18:25:55 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s9DFPtZe013264; Mon, 13 Oct 2014 18:25:55 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21563.61187.344567.586916@fireball.kivinen.iki.fi> Date: Mon, 13 Oct 2014 18:25:55 +0300 From: Tero Kivinen To: James Hulka In-Reply-To: <7452_1413160811_543B1F6B_7452_6802_1_543B1F65.3090206@open.ch> References: <7452_1413160811_543B1F6B_7452_6802_1_543B1F65.3090206@open.ch> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 16 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/9xKG277B5AZjLJsWcdtHpAJtaO0 Cc: ipsec@ietf.org, Roman Hoog Antink , Stefan Keller Subject: [IPsec] IKEv2 protocol race condition for auto start X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 15:26:02 -0000 James Hulka writes: > Dear IPsec Working Group, > > there is a race condition in the current IKEv2 protocol when 2 site > peers are configured to automatically establish a IPsec tunnel. > > Both peers can successfully initiate the IKE_SAs which results in > each peer having 2 options available for further communication. If > each peer selects a different IKE_SA, communication is blocked. Why? It is completely valid to have two IKE SAs between the peers, and both of them should work. It will also get two IPsec SA pairs, and that is completely valid situation again, and traffic might use any of the SAs between the peers. > We reported this as an issue in the StrongSwan mailing list in 2013 > (https://www.mail-archive.com/dev@lists.strongswan.org/msg00731.html) > and although they have a mechanism to prevent this, it does not > catch ALL cases. They are very strict about being RFC compliant > (which is good) and therefore could not correct the issue in their > IPsec daemon. If they somehow block traffic from the one IKE SA and keep the other one up and running, then that is not following the RFC. One of the problems might be caused by the INITIAL_CONTACT notifications, but in case of simultaneous connect, it should not be sent. I.e. when peer is sending IKE_AUTH it should already see the another half-open connection, which means this SA is no longer only IKE SA currently active between the peers, so it should not send INITIAL_CONTACT. > Currently we handle such cases with a script that is called by a > hook when an IPsec tunnel is established. In this script we check > for multiple IKE_SAs for a given tunnel and if found remove the > IKE_SA with the lower SA ID. If you try to just work against your own implementation that might work. That should not be needed, you just be able to use two IKE SAs and be done with it. It does not matter which IKE SA is used, they are same. It will consume more resources, and if this kind of simultaneous boot happen all the time, it is better to confiure only one end to create the connection, in which case this issue cannot happen. > It would be good if such a case could be handled in the IKE protocol > itself as in the case of site to site IPsec it is often a > requirement that a tunnel can be automatically re established after > a long connectivity outage. In a large mesh topology this gets very > complicated to keep track of which host should automatically > reconnect and which host should passively wait for a connection on a > per tunnel basis. Oh, you can make very easy heuristics for that, for example the peer which have smaller IP-address will always initiate. Or just allow two IKE SAs in such situations. -- kivinen@iki.fi From nobody Tue Oct 14 19:21:10 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B568B1A016F for ; Tue, 14 Oct 2014 19:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 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.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3X5HXwWXgNc for ; Tue, 14 Oct 2014 19:21:06 -0700 (PDT) Received: from mx2.open.ch (mx2.open.ch [213.156.239.108]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 511771A016D for ; Tue, 14 Oct 2014 19:21:06 -0700 (PDT) Received: from mx2.open.ch (localhost [127.0.0.1]) by mx2.open.ch (Mission Control Email Shield, 616) with SMTP id 3jHcmx06vYzjg3 for ; Wed, 15 Oct 2014 04:21:05 +0200 (MEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open.ch; s=mail_201403; t=1413339664; bh=yjGmtq4lPXjqTBSpwgdu2BLvbZWxvZdzwnm2/Dv6eZI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=j9Dui9PcnXW2csEiD5c/takVSmDmxyaUJITk6aWjk/MMGAB4TR2/gsSvGHp9h+7xl eismX6ZV18jEl3SxcLbetjcIFuLNRnESMyvbiE19fNUkxF6AxcsiGG2hp/NPl/2+C4 /rmLtXDum7A8Q+k3wnkeTAeypbitnPDOlyW19u8Q= Message-ID: <14944_1413339665_543DDA11_14944_1001_1_543DDA0C.8020909@open.ch> Date: Wed, 15 Oct 2014 13:21:00 +1100 From: James Hulka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: ipsec@ietf.org References: <543C59C1.4090002@open.ch> In-Reply-To: <543C59C1.4090002@open.ch> X-Forwarded-Message-Id: <543C59C1.4090002@open.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/GEB02DNhmD5kGPdXK7RutC6-cJw Subject: Re: [IPsec] IKEv2 protocol race condition for auto start X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 02:21:08 -0000 Dear Tero, thank you for your detailed explanation. On 14/10/14 02:25 AM, Tero Kivinen wrote: > James Hulka writes: >> Dear IPsec Working Group, >> >> there is a race condition in the current IKEv2 protocol when 2 site >> peers are configured to automatically establish a IPsec tunnel. >> >> Both peers can successfully initiate the IKE_SAs which results in >> each peer having 2 options available for further communication. If >> each peer selects a different IKE_SA, communication is blocked. > Why? It is completely valid to have two IKE SAs between the peers, and > both of them should work. > > It will also get two IPsec SA pairs, and that is completely valid > situation again, and traffic might use any of the SAs between the > peers. > >> We reported this as an issue in the StrongSwan mailing list in 2013 >> (https://www.mail-archive.com/dev@lists.strongswan.org/msg00731.html) >> and although they have a mechanism to prevent this, it does not >> catch ALL cases. They are very strict about being RFC compliant >> (which is good) and therefore could not correct the issue in their >> IPsec daemon. > If they somehow block traffic from the one IKE SA and keep the other > one up and running, then that is not following the RFC. > > One of the problems might be caused by the INITIAL_CONTACT > notifications, but in case of simultaneous connect, it should not be > sent. I.e. when peer is sending IKE_AUTH it should already see the > another half-open connection, which means this SA is no longer only > IKE SA currently active between the peers, so it should not send > INITIAL_CONTACT. So in a situation where both peers send IKE_SA_INIT and receive IKE_SA_INIT responses simultaneously they will both NOT send IKE_AUTH. I assume with connection retries this would continue until one peer can send IKE_AUTH before the other peer gets an IKE_SA_INIT response? >> Currently we handle such cases with a script that is called by a >> hook when an IPsec tunnel is established. In this script we check >> for multiple IKE_SAs for a given tunnel and if found remove the >> IKE_SA with the lower SA ID. > If you try to just work against your own implementation that might > work. That should not be needed, you just be able to use two IKE SAs > and be done with it. It does not matter which IKE SA is used, they are > same. It will consume more resources, and if this kind of simultaneous > boot happen all the time, it is better to confiure only one end to > create the connection, in which case this issue cannot happen. > >> It would be good if such a case could be handled in the IKE protocol >> itself as in the case of site to site IPsec it is often a >> requirement that a tunnel can be automatically re established after >> a long connectivity outage. In a large mesh topology this gets very >> complicated to keep track of which host should automatically >> reconnect and which host should passively wait for a connection on a >> per tunnel basis. > Oh, you can make very easy heuristics for that, for example the peer > which have smaller IP-address will always initiate. This is true but the decision for auto start everywhere is to make the configuration easier to understand for Engineers who may be required to debug such tunnels and maintain the code configuring such tunnels. It is a practicality/scale-ability decision based on the K.I.S.S (Keep it simple ...) principal. > Or just allow two IKE SAs in such situations. This interests me more but of course is out of the scope of this mailing list as it is possibly a misconfiguration or vendor issue. From nobody Wed Oct 15 21:12:33 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9279F1A0151 for ; Wed, 15 Oct 2014 21:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D58s6NPM9DZP for ; Wed, 15 Oct 2014 21:12:31 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2EB11A014E for ; Wed, 15 Oct 2014 21:12:27 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id b6so2134844lbj.31 for ; Wed, 15 Oct 2014 21:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CMmotHVPgJo4Ea4cwKnjU18gHYPCay16y2MutPOzz4U=; b=nWFSlZwAtrLMk9XRupw7B+2y/jUAHgzC540KG2h5qd4WcBPhZcyOM+dMvGvjrqCTZS jA1exIhB/jIxf0VN0tpeMc/UyFAgkddcl3K2pjsPRKCM3v9A3FEmzvvwfNWly3JgA6bK SOt8UJpP6REeaM148hdo+KC5UVqGAeE+kilRY/kGJFbEpEpHGZFNnsnPwfLpt5eExYF+ CO5TTWwzH/3lsKy14I9N/jCqubQwU6g6DeiEw0c/yqRJ1UNfvbGCA7NnXCmkKj4baBqV 0QHBr4h249Z+3AKP79hjHFcUtt7kmXskekVFPllDu3knUR+nTWRxrYP10+o0HtZF5PTb +4pw== MIME-Version: 1.0 X-Received: by 10.112.167.130 with SMTP id zo2mr16801558lbb.4.1413432746205; Wed, 15 Oct 2014 21:12:26 -0700 (PDT) Received: by 10.25.143.203 with HTTP; Wed, 15 Oct 2014 21:12:26 -0700 (PDT) Date: Thu, 16 Oct 2014 10:12:26 +0600 Message-ID: From: Fahima Ahmed Khan Etha To: IPsec@ietf.org Content-Type: multipart/alternative; boundary=001a11c33e96c06a210505827482 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/fCyB6vNRP-gTjD8cRGh1uPrceG0 Subject: [IPsec] How to know if you are hacked or not X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 04:12:32 -0000 --001a11c33e96c06a210505827482 Content-Type: text/plain; charset=UTF-8 Dear All, It might be an off topic. But I am seeking guidance from all of you. If any hacker group claimed that you are hacked... How to proof or find out its authenticity? Please share your view. Best regards, Fahima --001a11c33e96c06a210505827482 Content-Type: text/html; charset=UTF-8

Dear All,

It might be an off topic. But I am seeking guidance from all of you.

If any hacker group claimed that you are hacked... How to proof or find out its authenticity?

Please share your view.

Best regards,

Fahima

--001a11c33e96c06a210505827482-- From nobody Thu Oct 16 04:30:23 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433221AD061 for ; Thu, 16 Oct 2014 04:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKUTGt8U2wN1 for ; Thu, 16 Oct 2014 04:30:14 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFB541AD068 for ; Thu, 16 Oct 2014 04:30:11 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id q108so2287581qgd.39 for ; Thu, 16 Oct 2014 04:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Mar++nial6Oigw4C1rzzWv2qIY/sUKdWar7MfJQOmsM=; b=UR8lIqA3e6oMACnkzyo07gciCidb4cyRneIxORZ742ZbOVQPbdE+JDetryjEISM5PP KCZesCT9nXjHM/J/Cs6ctQHYghBT9EXeDDNmeLt7NY7VSu1C74sHXlB1HYtCPjo18l1S 8HgzlT2qb8v1RFvEHho46bUtjXKQnFZinT86iLM9ajLt4EssunDvJedWJJATuGJyREuk PHe0Ziu6+OJ/tMW/s8aEX0wqvuym48FT1MEBhlT5YlyTsx5qlRn+8/Hr6uZSjToozseS omkW1KvoMmzQGIYQK51VgHZDvK26H9AeyT3VXWPcm+APQKzyJ1aeFSxdj+qBSbw6SuEP Vn4g== X-Received: by 10.224.57.129 with SMTP id c1mr972239qah.21.1413459010900; Thu, 16 Oct 2014 04:30:10 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id k4sm21175830qaf.0.2014.10.16.04.30.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 04:30:09 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-F9EA0114-E79A-4E2B-BF9F-2EC6E1C32487 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Thu, 16 Oct 2014 07:30:08 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: To: Fahima Ahmed Khan Etha Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/gsZgK6oqVlT9gdHvtXyw2BC6hgc Cc: "IPsec@ietf.org" Subject: Re: [IPsec] How to know if you are hacked or not X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 11:30:17 -0000 --Apple-Mail-F9EA0114-E79A-4E2B-BF9F-2EC6E1C32487 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable If interested in this discussion, let's respond on the SAAG list and not acr= oss all lists. Thank you, Kathleen Sent from my iPhone > On Oct 16, 2014, at 12:12 AM, Fahima Ahmed Khan Etha wr= ote: >=20 > Dear All, >=20 > It might be an off topic. But I am seeking guidance from all of you. >=20 > If any hacker group claimed that you are hacked... How to proof or find ou= t its authenticity? >=20 > Please share your view. >=20 > Best regards, > Fahima >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail-F9EA0114-E79A-4E2B-BF9F-2EC6E1C32487 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
If interested in this discussion, let's respond on the SAAG list and not across all lists.

Thank you,
Kathleen

Sent from my iPhone

On Oct 16, 2014, at 12:12 AM, Fahima Ahmed Khan Etha <etha4u@gmail.com> wrote:

Dear All,

It might be an off topic. But I am seeking guidance from all of you.

If any hacker group claimed that you are hacked... How to proof or find out its authenticity?

Please share your view.

Best regards,

Fahima

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--Apple-Mail-F9EA0114-E79A-4E2B-BF9F-2EC6E1C32487-- From nobody Wed Oct 22 00:28:03 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9120A1A8AE1; Wed, 22 Oct 2014 00:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4r4sTx4FTgue; Wed, 22 Oct 2014 00:27:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A32D1A8AD8; Wed, 22 Oct 2014 00:27:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141022072757.9659.13568.idtracker@ietfa.amsl.com> Date: Wed, 22 Oct 2014 00:27:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/6Z3VJ1LshK2SrNYpzso7vasrZIw Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-null-auth-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 07:27:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : The NULL Authentication Method in IKEv2 Protocol Author : Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-null-auth-01.txt Pages : 10 Date : 2014-10-22 Abstract: This document introduces the NULL authentication method for the IKEv2 Protocol. This method provides a way to omit peer authentication in the IKEv2. It may be used to preserve anonymity of or in the situations, where no trust relationship exists between the parties. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-null-auth-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 22 00:49:14 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBF91A8AE9 for ; Wed, 22 Oct 2014 00:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 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, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMuX8zLIRFWg for ; Wed, 22 Oct 2014 00:49:12 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759D71A8AEB for ; Wed, 22 Oct 2014 00:49:12 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id z11so2271578lbi.41 for ; Wed, 22 Oct 2014 00:49:10 -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-type:content-transfer-encoding; bh=tNB6R0BZRR5uiIbHlKgPE8N9qdf+wxaE1WlO8way82Q=; b=KYF1GMBG3r7f/tXPA/u/YHG885Pm2Xeg9SLebPsP6Un3CwOEZljKT7sCMkWpCacfai l0MaAGQI+1vBD28w70F73te2npwLnYh0pe5EHgdRH100A46+09EYnjXYUVJjYWlBxasY ZcMUbKOQLmSipPZoZM/dv/EJ8B4Vo9L6srkO/396BEkgu/zX79l1yRGaOYIgnnrMqO4P cPOfd1n32ahu3z+ZIfFjwTNELayBJxGcWrVjILEZaGWEpTGTG6dth6WzCcEVgln0zhI8 6bkM/oWffNdTWKrGS2CaiyyOOoFGjiHqx9//9NUpsr+QG4M9cqix9wtGqPT5rMztLQqO Qz3Q== X-Received: by 10.152.44.233 with SMTP id h9mr39734990lam.73.1413964150773; Wed, 22 Oct 2014 00:49:10 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id k3sm5460631lam.33.2014.10.22.00.49.09 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 22 Oct 2014 00:49:09 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: References: <20141022072757.9659.13568.idtracker@ietfa.amsl.com> Date: Wed, 22 Oct 2014 11:49:08 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/KuU1kmckrp0lqt3D-bwO5_J7gc8 Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-null-auth-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 07:49:14 -0000 Hi all, I've posted a new version of the document. The list of changes: - some text is added about interaction with the INITIAL_CONTACT notification (this notification must be ignored by receiver) - a few words are added to Security Considerations based on discussion during the call for adoption - some grammar errors are fixed I think that the Security Considerations section is still incomplete. Please, feel free to suggest the text that should be added there. Regards, Valery Smyslov. ----- Original Message ----- From: To: Cc: Sent: Wednesday, October 22, 2014 11:27 AM Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-null-auth-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Security Maintenance and Extensions > Working Group of the IETF. > > Title : The NULL Authentication Method in IKEv2 Protocol > Author : Valery Smyslov > Filename : draft-ietf-ipsecme-ikev2-null-auth-01.txt > Pages : 10 > Date : 2014-10-22 > > Abstract: > This document introduces the NULL authentication method for the IKEv2 > Protocol. This method provides a way to omit peer authentication in > the IKEv2. It may be used to preserve anonymity of or in the > situations, where no trust relationship exists between the parties. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-null-auth-01 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Oct 23 08:11:37 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CFF1ACDA0 for ; Wed, 22 Oct 2014 08:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StJ6ae5T7QSl for ; Wed, 22 Oct 2014 08:52:39 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84C31ACD99 for ; Wed, 22 Oct 2014 08:52:39 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by gateway2.nyi.internal (Postfix) with ESMTP id 1A8932788 for ; Wed, 22 Oct 2014 11:52:39 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 22 Oct 2014 11:52:39 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:from:content-type:subject:date :references:to:message-id:mime-version; s=smtpout; bh=vuaF4cWu1M iRVuIWfS0Mea4QAPM=; b=LEduUqWN1ZqQIcr81ekmOhm838N3WA93+8fj3Myurq UdBRba4zprLV/jM9DxrHFBT/8rsXeXlAlAyZBh226irsqWVUG0NX7sk3IlEaDP6e VbuNhZciq1sZUThoURbe9ub+oVMGSBlvFGfo4mWj4wqWUhplr9cZ0alx1amCkBWp g= X-Sasl-enc: MlQ/YJXkbmAJvX2QOdo5LFzWJOURo6L6MQdAKKBhtUNr 1413993158 Received: from eng-148.ma.arbor.net (unknown [23.30.178.193]) by mail.messagingengine.com (Postfix) with ESMTPA id 209EAC00011; Wed, 22 Oct 2014 11:52:38 -0400 (EDT) From: Bill Cerveny Content-Type: multipart/alternative; boundary="Apple-Mail=_4AF4DC2E-7C25-4A7C-81CF-E75B407B6E48" Date: Wed, 22 Oct 2014 11:52:37 -0400 References: <20140919143517.9076.18495.idtracker@ietfa.amsl.com> To: ippm@ietf.org, ipsec@ietf.org Message-Id: <50C83F71-5733-4733-A8A3-D89817DFCF21@wjcerveny.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/BME3l1udGTo_csws2YqnuPyUhF8 X-Mailman-Approved-At: Thu, 23 Oct 2014 08:11:27 -0700 Subject: [IPsec] WGLC: draft-ietf-ippm-ipsec-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:52:41 -0000 --Apple-Mail=_4AF4DC2E-7C25-4A7C-81CF-E75B407B6E48 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [Resending to include ipsec e-mail list] A WGLC is being commenced for draft-ietf-ippm-ipsec until Saturday, = November 1, 2014. The authors are particularly interested in comments = regarding changes made to the document since IETF90. These changed can = be observed at: = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-ippm-ipsec-04&difftype=3D--= html&submit=3DGo%21&url2=3Ddraft-ietf-ippm-ipsec-05 Regards, Bill Cerveny IPPM WG co-chair Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [ippm] I-D Action: draft-ietf-ippm-ipsec-05.txt > Date: September 19, 2014 at 10:35:17 AM EDT > To: i-d-announce@ietf.org > Cc: ippm@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Performance Metrics Working Group = of the IETF. >=20 > Title : IKEv2-based Shared Secret Key for O/TWAMP > Authors : Kostas Pentikousis > Emma Zhang > Yang Cui > Filename : draft-ietf-ippm-ipsec-05.txt > Pages : 12 > Date : 2014-09-19 >=20 > Abstract: > The O/TWAMP security mechanism requires that both the client and > server endpoints possess a shared secret. Since the currently- > standardized O/TWAMP security mechanism only supports a pre-shared > key mode, large scale deployment of O/TWAMP is hindered > significantly. At the same time, recent trends point to wider IKEv2 > deployment which, in turn, calls for mechanisms and methods that > enable tunnel end-users, as well as operators, to measure one-way = and > two-way network performance in a standardized manner. This document > discusses the use of keys derived from an IKEv2 SA as the shared key > in O/TWAMP. If the shared key can be derived from the IKEv2 SA, O/ > TWAMP can support certificate-based key exchange, which would allow > for more operational flexibility and efficiency. The key derivation > presented in this document can also facilitate automatic key > management. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ippm-ipsec-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-ipsec-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_4AF4DC2E-7C25-4A7C-81CF-E75B407B6E48 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii [Resending to include ipsec e-mail = list]

A WGLC is being commenced for = draft-ietf-ippm-ipsec until Saturday, November 1, 2014.  The = authors are particularly interested in comments regarding changes made = to the document since IETF90. These changed can be observed at:
Regards,

Bill = Cerveny
IPPM WG co-chair

Begin forwarded = message:

From: = internet-drafts@ietf.org
<= /span>
Subject: = [ippm] I-D = Action: draft-ietf-ippm-ipsec-05.txt
Date: September 19, 2014 at 10:35:17 AM = EDT

<= br>A New Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the IP Performance Metrics = Working Group of the IETF.

=        Title =           : = IKEv2-based Shared Secret Key for O/TWAMP
=        Authors =         : Kostas Pentikousis
=             &n= bsp;           &nbs= p;Emma Zhang
=             &n= bsp;           &nbs= p;Yang Cui
= Filename        : = draft-ietf-ippm-ipsec-05.txt
Pages =           : = 12
= Date =            : = 2014-09-19

Abstract:
  The O/TWAMP security = mechanism requires that both the client and
  server = endpoints possess a shared secret.  Since the currently-
=   standardized O/TWAMP security mechanism only supports a = pre-shared
  key mode, large scale deployment of O/TWAMP = is hindered
  significantly.  At the same time, = recent trends point to wider IKEv2
  deployment which, in = turn, calls for mechanisms and methods that
  enable = tunnel end-users, as well as operators, to measure one-way and
=   two-way network performance in a standardized manner. =  This document
  discusses the use of keys derived = from an IKEv2 SA as the shared key
  in O/TWAMP.  If = the shared key can be derived from the IKEv2 SA, O/
=   TWAMP can support certificate-based key exchange, which = would allow
  for more operational flexibility and = efficiency.  The key derivation
  presented in this = document can also facilitate automatic key
=   management.


The IETF datatracker status page for = this draft is:
https://d= atatracker.ietf.org/doc/draft-ietf-ippm-ipsec/

There's also a = htmlized version available at:
http://tools.= ietf.org/html/draft-ietf-ippm-ipsec-05

A diff from the = previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-ipsec-05

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

Internet-Drafts are also available by anonymous = FTP = at:
ftp://ftp.ietf.org/internet-drafts/

________________________= _______________________
ippm mailing = list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

= --Apple-Mail=_4AF4DC2E-7C25-4A7C-81CF-E75B407B6E48-- From nobody Fri Oct 24 16:18:10 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D471A1B91; Fri, 24 Oct 2014 16:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eywpVxERXABR; Fri, 24 Oct 2014 16:18:03 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 473E01A1A0F; Fri, 24 Oct 2014 16:18:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A155D181C73; Fri, 24 Oct 2014 16:17:32 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20141024231732.A155D181C73@rfc-editor.org> Date: Fri, 24 Oct 2014 16:17:32 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/TUMO2JkdDr9xi5OOSykaHZ2rkDU Cc: ipsec@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org Subject: [IPsec] STD 79, RFC 7296 on Internet Key Exchange Protocol Version 2 (IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 23:18:05 -0000 A new Request for Comments is now available in online RFC libraries. STD 79 RFC 7296 Title: Internet Key Exchange Protocol Version 2 (IKEv2) Author: C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen Status: Standards Track Stream: IETF Date: October 2014 Mailbox: charliekaufman@outlook.com, paul.hoffman@vpnc.org, nir.ietf@gmail.com, pe@iki.fi, kivinen@iki.fi Pages: 142 Characters: 354358 Obsoletes: RFC 5996 See Also: STD 79 I-D Tag: draft-kivinen-ipsecme-ikev2-rfc5996bis-04.txt URL: https://www.rfc-editor.org/rfc/rfc7296.txt This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now an Internet Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sat Oct 25 00:35:43 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330EA1A700B for ; Sat, 25 Oct 2014 00:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCc4oBvrlZ7f for ; Sat, 25 Oct 2014 00:35:40 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DD2F1A6FFC for ; Sat, 25 Oct 2014 00:35:39 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id pv20so3628105lab.6 for ; Sat, 25 Oct 2014 00:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=zSq/Y5Az8GsWtNpCeecbBUWb1XFuFMTIcV7Amb0dpaA=; b=Bb/rElHlSHbGjlv4jA3gVUlPpsurokDYAEzOQI4AmSvZTxbonLfSk0npIJgM81EDn1 taS0i1u/QxyM/Tqacze1nW3ug4edMerL3vQF9jK9JzwckIgVs0XIe4CPf5JZDaFIEFHn 2DqHaebEQmG5jb9IeEWySNy6QDKGH3CfO50rrf3o3/yfFtgo2Ig8S+8iCERt2jDne9h1 7FlhkbDvzfU6thWloc8dO25qScmzwR+nCSkHi8zXLOw8Bimx/3IO6yama0gGBBnOFQsk M+AMXHE7T6szuAOCi/98zV/tQHpCKG3MRMmdbKroDaIds06q4bfEpJ04krs5eXFtV8Xg Bcfg== X-Received: by 10.112.48.3 with SMTP id h3mr9390312lbn.71.1414222538355; Sat, 25 Oct 2014 00:35:38 -0700 (PDT) Received: from [10.0.0.4] (bzq-79-180-101-176.red.bezeqint.net. [79.180.101.176]) by mx.google.com with ESMTPSA id z2sm2635077laa.15.2014.10.25.00.35.36 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Oct 2014 00:35:37 -0700 (PDT) Message-ID: <544B52C7.2090304@gmail.com> Date: Sat, 25 Oct 2014 10:35:35 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: ipsec References: <20141024231732.A155D181C73@rfc-editor.org> In-Reply-To: <20141024231732.A155D181C73@rfc-editor.org> X-Forwarded-Message-Id: <20141024231732.A155D181C73@rfc-editor.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/VI3sc8zVtyPUcU6r5wzJKeGnlEk Subject: [IPsec] Fwd: STD 79, RFC 7296 on Internet Key Exchange Protocol Version 2 (IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 07:35:42 -0000 This is the first Internet Standard to do with an IPsec protocol. Thanks Sean Turner for initiating this work, and Tero Kivinen for making it happen! Paul and Yaron -------- Forwarded Message -------- Subject: STD 79, RFC 7296 on Internet Key Exchange Protocol Version 2 (IKEv2) Date: Fri, 24 Oct 2014 16:17:32 -0700 (PDT) From: rfc-editor@rfc-editor.org Reply-To: ietf@ietf.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: ipsec@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. STD 79 RFC 7296 Title: Internet Key Exchange Protocol Version 2 (IKEv2) Author: C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen Status: Standards Track Stream: IETF Date: October 2014 Mailbox: charliekaufman@outlook.com, paul.hoffman@vpnc.org, nir.ietf@gmail.com, pe@iki.fi, kivinen@iki.fi Pages: 142 Characters: 354358 Obsoletes: RFC 5996 See Also: STD 79 I-D Tag: draft-kivinen-ipsecme-ikev2-rfc5996bis-04.txt URL: https://www.rfc-editor.org/rfc/rfc7296.txt This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now an Internet Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Oct 27 08:36:36 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1495A1A88BD; Mon, 27 Oct 2014 08:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pk1jJLjQJUnW; Mon, 27 Oct 2014 08:36:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 284D41A8F41; Mon, 27 Oct 2014 08:36:30 -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: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027153630.31068.57133.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 08:36:30 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/DpgMifOYDY2Z-Todkk4MZroAbqY Cc: ipsecme mailing list , ipsecme chair , RFC Editor Subject: [IPsec] Protocol Action: 'Signature Authentication in IKEv2' to Proposed Standard (draft-kivinen-ipsecme-signature-auth-07.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 15:36:34 -0000 The IESG has approved the following document: - 'Signature Authentication in IKEv2' (draft-kivinen-ipsecme-signature-auth-07.txt) as Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Kathleen Moriarty and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-signature-auth/ Technical Summary This document generalizes the IKEv2 signature support so it can support any signature method supported by the PKIX and also adds signature hash algorithm negotiation. This means that all types of signatures, not just RSA and ECDSA, and any type of elliptic curves can be supported. Working Group Summary The WG discussion of the document was very good, with wide consensus for adoption. There were no objections to adoption. There were only a few small changes requested during IETF Last Call, which were addressed by the authors. Document Quality The draft went through an extensive editorial revision after WG Last Call, and that version was last called again in the WG. Joel Snyder was added as co-author. This is a protocol extension and is meant for proposed standard. Personnel Paul Hoffman (IPsecME WG co-chair) is the document shepherd and Kathleen Moriarty is the responsible AD. The IANA Expert(s) for the registries in this document are to be by expert review, likely the document editor. From nobody Mon Oct 27 11:13:29 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0409B1A038C for ; Mon, 27 Oct 2014 11:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.701 X-Spam-Level: X-Spam-Status: No, score=-96.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKqDHvx_pKRc for ; Mon, 27 Oct 2014 11:13:12 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A1D41A0194 for ; Mon, 27 Oct 2014 11:13:11 -0700 (PDT) Received: from [192.168.0.2] (cpe-066-057-017-031.nc.res.rr.com [66.57.17.31]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C452B27817F; Tue, 28 Oct 2014 03:13:07 +0900 (JST) From: Rodney Van Meter Content-Type: multipart/alternative; boundary="Apple-Mail=_02E19B68-5D97-4A3C-8DD6-14B9FB78F098" Date: Mon, 27 Oct 2014 14:13:06 -0400 Message-Id: <9FA67F6A-A730-46FC-925E-F16A1B686D73@sfc.wide.ad.jp> To: ipsec Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/0L8wbPRoL8sV593tl-8m7bFn5Is Cc: Rodney Van Meter , Shota Nagayama , Shigeya Suzuki Subject: [IPsec] IPsec with QKD X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 18:13:15 -0000 --Apple-Mail=_02E19B68-5D97-4A3C-8DD6-14B9FB78F098 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Those of you with long-ish memories will recall that about three years = ago, Shota Nagayama and I wrote an I-D on the (relatively minor) = modifications to IKEv2 necessary to use key material generated by = quantum key distribution (QKD) devices. At the time, it generated a bit = of controversy, both because not everyone in the WG agrees on the value = of QKD itself (a position I understand, though happen to disagree with) = and because there were concerns about whether it is within charter for = ipsecme. So, it more or less got set aside. We have since talked to a = number of people who are supportive of having a documented means of = coupling IPsec to QKD, without necessarily taking a strong position on = whether QKD will ultimately hold a large place in the security market. = Being one who hates leaving loose ends lying around, I would like to = finish this up and get it published as an RFC, presumably Experimental. The basic argument in favor of doing so: * several commercial and near-commercial implementations of QKD exist = (along with numerous experimental ones); * each implementation uses the generated key material in a different = way, some at L2, some with IPsec; * ETSI began standardizing some of the low-level technologies, including = physical signals and timing and framing; * experimental deployments are continuing to grow, and those deployments = may include IPsec; and * given that IPsec and IKE are products of the IETF, any necessary = changes should be documented and controlled through IETF rather than = another organization. That last point is, I think, critical. Current status: * We have just uploaded an -01 of the I-D we wrote, incorporating = feedback from several people, including Sean Turner, Sheila Frankel and = Alan Mink. = http://datatracker.ietf.org/doc/draft-nagayama-ipsecme-ipsec-with-qkd/?inc= lude_text=3D1 * An open source software implementation of the -00 version exists, = built off of raccoon2. We will be updating this to match the -01 draft. Shota and I (and Shigeya Suzuki, who is not an author on the draft but = is familiar with our work) will be in Honolulu. I will arrive Monday = evening, leaving Thursday evening. We hope to meet with folks who are = interested in this topic. Happy to answer questions via email, as well. Regards, =97Rod Rodney Van Meter associate professor, Faculty of Environment and Information Studies, = Keio University, Japan rdv@sfc.wide.ad.jp personal: http://web.sfc.keio.ac.jp/~rdv/ AQUA Group: http://aqua.sfc.wide.ad.jp/ Murai Lab: http://www.sfc.wide.ad.jp/IRL/ GIGA: http://ic.sfc.keio.ac.jp/ Quantum Networking: = http://www.wiley.com/WileyCDA/WileyTitle/productCd-1848215371.html http://discourse.quantumnetworks.org/ --Apple-Mail=_02E19B68-5D97-4A3C-8DD6-14B9FB78F098 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Those = of you with long-ish memories will recall that about three years ago, = Shota Nagayama and I wrote an I-D on the (relatively minor) = modifications to IKEv2 necessary to use key material generated by = quantum key distribution (QKD) devices.  At the time, it generated = a bit of controversy, both because not everyone in the WG agrees on the = value of QKD itself (a position I understand, though happen to disagree = with) and because there were concerns about whether it is within charter = for ipsecme.  So, it more or less got set aside.  We have = since talked to a number of people who are supportive of having a = documented means of coupling IPsec to QKD, without necessarily taking a = strong position on whether QKD will ultimately hold a large place in the = security market.  Being one who hates leaving loose ends lying = around, I would like to finish this up and get it published as an RFC, = presumably Experimental.

The basic argument in = favor of doing so:

* several commercial and = near-commercial implementations of QKD exist (along with numerous = experimental ones);
* each implementation uses the generated = key material in a different way, some at L2, some with = IPsec;
* ETSI began standardizing some of the low-level = technologies, including physical signals and timing and = framing;
* experimental deployments are continuing to grow, = and those deployments may include IPsec; and
* given that = IPsec and IKE are products of the IETF, any necessary changes should be = documented and controlled through IETF rather than another = organization.

That last point is, I think, = critical.

Current = status:

* We have just uploaded an -01 of the = I-D we wrote, incorporating feedback from several people, including Sean = Turner, Sheila Frankel and Alan Mink.
* An open source = software implementation of the -00 version exists, built off of = raccoon2.  We will be updating this to match the -01 = draft.

Shota and I (and Shigeya Suzuki, = who is not an author on the draft but is familiar with our work) will be = in Honolulu.  I will arrive Monday evening, leaving Thursday = evening.  We hope to meet with folks who are interested in this = topic.  Happy to answer questions via email, as = well.

Regards,

= =97Rod

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


= --Apple-Mail=_02E19B68-5D97-4A3C-8DD6-14B9FB78F098-- From nobody Mon Oct 27 11:19:10 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FEB1A8991 for ; Mon, 27 Oct 2014 11:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.407 X-Spam-Level: X-Spam-Status: No, score=-98.407 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIRzZ_jKaZ-E for ; Mon, 27 Oct 2014 11:18:47 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C0A1A8985 for ; Mon, 27 Oct 2014 11:18:47 -0700 (PDT) Received: from [192.168.0.2] (cpe-066-057-017-031.nc.res.rr.com [66.57.17.31]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 6DB4C27817F; Tue, 28 Oct 2014 03:18:44 +0900 (JST) Content-Type: multipart/alternative; boundary="Apple-Mail=_AEE3FDA7-881C-45D1-8522-8E21F888C208" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Rodney Van Meter In-Reply-To: <9FA67F6A-A730-46FC-925E-F16A1B686D73@sfc.wide.ad.jp> Date: Mon, 27 Oct 2014 14:18:40 -0400 Message-Id: <5A91B44F-B57F-4705-8EC8-ED7A19AF98A3@sfc.wide.ad.jp> References: <9FA67F6A-A730-46FC-925E-F16A1B686D73@sfc.wide.ad.jp> To: ipsec X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/LYPNV27PZsPeb1GQBCsyAB3tgNI Cc: Rodney Van Meter , Shota Nagayama , Shigeya Suzuki Subject: Re: [IPsec] IPsec with QKD X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 18:18:49 -0000 --Apple-Mail=_AEE3FDA7-881C-45D1-8522-8E21F888C208 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 27, 2014, at 2:13 PM, Rodney Van Meter = wrote: >=20 >=20 > Current status: >=20 > * We have just uploaded an -01 of the I-D we wrote, incorporating = feedback from several people, including Sean Turner, Sheila Frankel and = Alan Mink. > = http://datatracker.ietf.org/doc/draft-nagayama-ipsecme-ipsec-with-qkd/?inc= lude_text=3D1 > * An open source software implementation of the -00 version exists, = built off of raccoon2. We will be updating this to match the -01 draft. >=20 Oh, one point I meant to mention=85IANA considerations: * We need a Transform Type Value for SA Payloads * We need Payload Type Values for QKD KeyID and QKD Fallback. =97Rod --Apple-Mail=_AEE3FDA7-881C-45D1-8522-8E21F888C208 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Oct 27, 2014, at 2:13 PM, Rodney = Van Meter <rdv@sfc.wide.ad.jp> = wrote:


Current = status:

* We have just uploaded an -01 of the = I-D we wrote, incorporating feedback from several people, including Sean = Turner, Sheila Frankel and Alan Mink.
* An open source = software implementation of the -00 version exists, built off of = raccoon2.  We will be updating this to match the -01 = draft.


Oh, = one point I meant to mention=85IANA = considerations:

* We need a Transform Type = Value for SA Payloads
* We need Payload Type Values for QKD = KeyID and QKD Fallback.

= =97Rod


= --Apple-Mail=_AEE3FDA7-881C-45D1-8522-8E21F888C208-- From nobody Mon Oct 27 14:31:50 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B9B1AD5B9 for ; Mon, 27 Oct 2014 14:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTprvMwwShCz for ; Mon, 27 Oct 2014 14:31:43 -0700 (PDT) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D56521AD5BB for ; Mon, 27 Oct 2014 14:30:20 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:MIME-Version:Return-Path; b=ZBXbCyczSscCN68tY9ENAAz7vL1iIzVD92qSFwpkofEd6f/kxD+D0pRM Ch1c+X5EKAlBjPB+KGgt8OJmsGxE/9yNs8AVm0wrEEyfgbqOhMHMAYsqA bxY48Yr3f4V7prUhOH5RV0nJVc6rnOmhfFJltr9RvHg+dSpbud6EMdkqo w=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1414445420; x=1445981420; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=9pJQN0iTr87pkzXfrlyiwJrSWh9NvKI+leJS2RbOWio=; b=goRUTDvA+9feERKna6/vP0txMwP76YOD/f5IfbP3q6aCVqAUirT49muK eDBSIgf71O/+4AgnvJ59+4wNh9Lt1FvsalFm4bxBTNbupfiFwmRIb6ZfN VXlERJe7Crt7SfFv/H/r849u0r5aae0CHqwdS0pN9rP6cI7rDunkkz+Jd s=; X-LoopCount0: from 10.175.216.249 X-IronPort-AV: E=Sophos;i="5.04,798,1406610000"; d="scan'208,217";a="714512567" From: To: Thread-Topic: [IPsec] IPsec with QKD Thread-Index: AQHP8hGnxyUwrEBowkSdbjGMq89vjJxEyhQA Date: Mon, 27 Oct 2014 21:30:18 +0000 Message-ID: <7134F6D8-587F-4EBA-8E23-C088D8F1EA25@dell.com> References: <9FA67F6A-A730-46FC-925E-F16A1B686D73@sfc.wide.ad.jp> In-Reply-To: <9FA67F6A-A730-46FC-925E-F16A1B686D73@sfc.wide.ad.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.177.90.69] Content-Type: multipart/alternative; boundary="_000_7134F6D8587F4EBA8E23C088D8F1EA25dellcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/V4XnargSq6Y090bCo0h1iqUkr-4 Cc: ipsec@ietf.org, kurosagi@sfc.wide.ad.jp, shigeya@wide.ad.jp Subject: Re: [IPsec] IPsec with QKD X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 21:31:47 -0000 --_000_7134F6D8587F4EBA8E23C088D8F1EA25dellcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable A nit in section 5: "The security of Diffie-Hellman depends on the difficu= lty of the factoring problem=94. More precisely, it depends on the difficu= lty of the modular discrete log problem, though it may be (I forgot if this= is proven or a conjecture) that an efficient solution of that problem can = be mapped to/from an efficient solution of the factoring problem. paul On Oct 27, 2014, at 2:13 PM, Rodney Van Meter > wrote: ... * We have just uploaded an -01 of the I-D we wrote, incorporating feedback = from several people, including Sean Turner, Sheila Frankel and Alan Mink. http://datatracker.ietf.org/doc/draft-nagayama-ipsecme-ipsec-with-qkd/?in= clude_text=3D1 --_000_7134F6D8587F4EBA8E23C088D8F1EA25dellcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <99D10A4109AC0B4E987C1BD6BEE5F02C@dell.com> Content-Transfer-Encoding: quoted-printable A nit in section 5:  "The security of Diffie-Hellman depends on t= he difficulty of the factoring problem=94.  More precisely, it depends= on the difficulty of the modular discrete log problem, though it may be (I= forgot if this is proven or a conjecture) that an efficient solution of that problem can be mapped to/from an efficient solu= tion of the factoring problem.

paul

On Oct 27, 2014, at 2:13 PM, Rodney Van Meter <rdv@sfc.wide.ad.jp> wrote:

...
* We have just uploaded an -01 of the I-D we wrote, incorporating feed= back from several people, including Sean Turner, Sheila Frankel and Alan Mi= nk.

--_000_7134F6D8587F4EBA8E23C088D8F1EA25dellcom_-- From nobody Mon Oct 27 14:44:51 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197A81A009C for ; Mon, 27 Oct 2014 14:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.401 X-Spam-Level: X-Spam-Status: No, score=-99.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8B9qk4OKTPZ for ; Mon, 27 Oct 2014 14:44:38 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EA011A00E9 for ; Mon, 27 Oct 2014 14:44:04 -0700 (PDT) Received: from [192.168.0.2] (cpe-066-057-017-031.nc.res.rr.com [66.57.17.31]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id AC3B827819C; Tue, 28 Oct 2014 06:43:59 +0900 (JST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2C5D95D6-6E41-4FC4-8961-7D38DBCF7343" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Rodney Van Meter In-Reply-To: <7134F6D8-587F-4EBA-8E23-C088D8F1EA25@dell.com> Date: Mon, 27 Oct 2014 17:43:54 -0400 Message-Id: References: <9FA67F6A-A730-46FC-925E-F16A1B686D73@sfc.wide.ad.jp> <7134F6D8-587F-4EBA-8E23-C088D8F1EA25@dell.com> To: Paul_Koning@Dell.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ONJSGi-kUnkrCWo4ZUBJZM17vbw Cc: Rodney Van Meter , ipsec@ietf.org, kurosagi@sfc.wide.ad.jp, shigeya@wide.ad.jp Subject: Re: [IPsec] IPsec with QKD X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 21:44:41 -0000 --Apple-Mail=_2C5D95D6-6E41-4FC4-8961-7D38DBCF7343 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yes, you=92re correct, we should be more exact there. Shor=92s algorithm solves both (if you believe in large-scale quantum = computers). Classically, I haven=92t studied the relationship in depth myself, but = this bachelor=92s thesis from Harvard seems to be a survey: http://modular.math.washington.edu/projects/john_gregg_thesis.pdf =97Rod On Oct 27, 2014, at 5:30 PM, = wrote: > A nit in section 5: "The security of Diffie-Hellman depends on the = difficulty of the factoring problem=94. More precisely, it depends on = the difficulty of the modular discrete log problem, though it may be (I = forgot if this is proven or a conjecture) that an efficient solution of = that problem can be mapped to/from an efficient solution of the = factoring problem. >=20 > paul >=20 > On Oct 27, 2014, at 2:13 PM, Rodney Van Meter = wrote: >=20 >> ... >> * We have just uploaded an -01 of the I-D we wrote, incorporating = feedback from several people, including Sean Turner, Sheila Frankel and = Alan Mink. >> = http://datatracker.ietf.org/doc/draft-nagayama-ipsecme-ipsec-with-qkd/?inc= lude_text=3D1 >=20 --Apple-Mail=_2C5D95D6-6E41-4FC4-8961-7D38DBCF7343 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Yes, = you=92re correct, we should be more exact = there.

Shor=92s algorithm solves both (if you believe = in large-scale quantum computers).

Classically, = I haven=92t studied the relationship in depth myself, but this = bachelor=92s thesis from Harvard seems to be a survey:
http://modular.math.washington.edu/projects/john_gregg_thesis.pdf

= =97Rod


On Oct 27, 2014, at = 5:30 PM, <Paul_Koning@Dell.com> <Paul_Koning@Dell.com> = wrote:

A nit in section 5:  "The security of Diffie-Hellman depends on the = difficulty of the factoring problem=94.  More precisely, it depends = on the difficulty of the modular discrete log problem, though it may be = (I forgot if this is proven or a conjecture) that an efficient solution of that problem can be mapped to/from an efficient = solution of the factoring problem.

paul

On Oct 27, 2014, at 2:13 PM, Rodney Van Meter <rdv@sfc.wide.ad.jp> = wrote:

...
* We have just uploaded an -01 of the I-D we wrote, incorporating = feedback from several people, including Sean Turner, Sheila Frankel and = Alan Mink.


= --Apple-Mail=_2C5D95D6-6E41-4FC4-8961-7D38DBCF7343-- From nobody Mon Oct 27 14:48:48 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A451A009C; Mon, 27 Oct 2014 14:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jON6IUxIUXLF; Mon, 27 Oct 2014 14:48:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C96D51A005C; Mon, 27 Oct 2014 14:48:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027214823.13103.25135.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 14:48:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/0koCxukcH7LhW-L-VBznYMCAuDI Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 21:48:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Protecting Internet Key Exchange (IKE) Implementations from Distributed Denial of Service Attacks Author : Yoav Nir Filename : draft-ietf-ipsecme-ddos-protection-00.txt Pages : 12 Date : 2014-10-27 Abstract: This document recommends implementation and configuration best practices for Internet-connected IPsec Responders, to allow them to resist Denial of Service and Distributed Denial of Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that help accomplish this task. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 29 07:55:11 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452DA1A0155 for ; Wed, 29 Oct 2014 07:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAbVEkANww5x for ; Wed, 29 Oct 2014 07:55:08 -0700 (PDT) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C9A1A0141 for ; Wed, 29 Oct 2014 07:55:07 -0700 (PDT) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XjUeO-0007Pm-I0 for ipsec@ietf.org; Wed, 29 Oct 2014 15:55:04 +0100 Received: from c73-202.rim.net ([208.65.73.202]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Oct 2014 15:55:04 +0100 Received: from laijus by c73-202.rim.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Oct 2014 15:55:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ipsec@ietf.org From: Justin Lai Date: Wed, 29 Oct 2014 14:38:40 +0000 (UTC) Lines: 15 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 208.65.73.202 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.104 Safari/537.36) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/w-Dix6c8wCSg3k6PakEu1NTIk4Y Subject: [IPsec] =?utf-8?q?RFC5723=3A_Calculating_auth_value_in_IKE=5FAUTH?= =?utf-8?q?_during_Session_resumption?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 14:55:09 -0000 Hi, I am having some problem understanding how AUTH value is calculated during IKE_AUTH when a session is resumed using RFC 5723. Is the AUTH value calculation always going to be AUTH = prf(SK_px, ) regardless of the auth type used? For example if the auth method used during login was RSA Digital Signature for both client and gateway auth, then on session resumption, should the auth value be computed using RSA private key as well or should the AUTH value be computed using prf(SK_px, )? Thanks From nobody Wed Oct 29 08:03:45 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDC61A0390 for ; Wed, 29 Oct 2014 08:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MpH6f2DlbS7 for ; Wed, 29 Oct 2014 08:03:34 -0700 (PDT) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 617301A036F for ; Wed, 29 Oct 2014 08:03:16 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:MIME-Version:Return-Path; b=TMga62rdhnUV3JJJvV8ReTLzva0R3hFdNn2krcX0O6bQeMob+6ESmgDf n+JFGjY91PmA7EiTsLbzTcmhD82jakZV0+msfSE2vg+QZQOe4iTOBzCGf sc2vt9iLKM3Oii1DUkY6mV31GUw0vklMZKAZGgSE7hjSp1w8EHohgNC/Z g=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1414594996; x=1446130996; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=9nDpHr5YMWaLp6mvnzhzhaX7cuF3P/Vsccfe+iAN7rk=; b=NEc3rm7+hNNfNr0pwIbZHWeSdJx1Qn8ad5p0IIFgrCW/Rwd0LcPp7NCx OVuplBvYZvYH+QusX47cOz5unLktJtst2c4Ft95Qw6REPqVpk8b0Ue/3q yhZKNMJqs1JfMVLMCUuYXM0CAgOFKKtaj3CO1Dwv1/tDTjQmgmJsrWbuY k=; X-LoopCount0: from 10.170.28.40 X-IronPort-AV: E=Sophos;i="5.04,810,1406610000"; d="scan'208,217";a="715237266" From: To: Thread-Topic: [IPsec] IPsec with QKD Thread-Index: AQHP8hGnxyUwrEBowkSdbjGMq89vjJxEyhQAgAK4ggA= Date: Wed, 29 Oct 2014 15:03:13 +0000 Message-ID: <264EF2D3-F00F-4D3C-9576-D61879AE9D44@dell.com> References: <9FA67F6A-A730-46FC-925E-F16A1B686D73@sfc.wide.ad.jp> <7134F6D8-587F-4EBA-8E23-C088D8F1EA25@dell.com> In-Reply-To: <7134F6D8-587F-4EBA-8E23-C088D8F1EA25@dell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.177.90.69] Content-Type: multipart/alternative; boundary="_000_264EF2D3F00F4D3C9576D61879AE9D44dellcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/54GIAZkdYPLp08LJMRODIJcJE1U Cc: ipsec@ietf.org, kurosagi@sfc.wide.ad.jp, shigeya@wide.ad.jp Subject: Re: [IPsec] IPsec with QKD X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:03:42 -0000 --_000_264EF2D3F00F4D3C9576D61879AE9D44dellcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I wonder if this should be worded more generically. This is really about a= n external key agreement mechanism. QKD is one such mechanism, but it isn= =92t clear to me that the machinery depends on this. Suppose, for example, that you distributed copies of one-time pad CDROMs to= both locations, and used the key ID as offset in the one-time-pad data. T= his is a completely different key agreement scheme but it would seem to fit= just as well. The important point is that there is an external source of = key material, which has the (assumed) property that the key material is kno= wn to the two endpoints of the IKE exchange, and to no other parties. paul On Oct 27, 2014, at 2:13 PM, Rodney Van Meter > wrote: ... * We have just uploaded an -01 of the I-D we wrote, incorporating feedback = from several people, including Sean Turner, Sheila Frankel and Alan Mink. http://datatracker.ietf.org/doc/draft-nagayama-ipsecme-ipsec-with-qkd/?in= clude_text=3D1 --_000_264EF2D3F00F4D3C9576D61879AE9D44dellcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9EAEC810185F67418B88C6C9FC301C68@dell.com> Content-Transfer-Encoding: quoted-printable
I wonder if this should be worded more generically.  This is real= ly about an external key agreement mechanism.  QKD is one such mechani= sm, but it isn=92t clear to me that the machinery depends on this.
Suppose, for example, that you distributed copies of one-time pad CDRO= Ms to both locations, and used the key ID as offset in the one-time-pad dat= a.  This is a completely different key agreement scheme but it would s= eem to fit just as well.  The important point is that there is an external source of key material, which has the (= assumed) property that the key material is known to the two endpoints of th= e IKE exchange, and to no other parties.

paul


On Oct 27, 2014, at 2:13 PM, Rodney Van Meter <rdv@sfc.wide.ad.jp> wrote:

...
* We have just uploaded an -01 of the I-D we wrote, incorporating feed= back from several people, including Sean Turner, Sheila Frankel and Alan Mi= nk.


--_000_264EF2D3F00F4D3C9576D61879AE9D44dellcom_-- From nobody Wed Oct 29 08:35:00 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC33B1A0179 for ; Wed, 29 Oct 2014 08:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.007 X-Spam-Level: X-Spam-Status: No, score=-97.007 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aA4a99I3v-zw for ; Wed, 29 Oct 2014 08:34:54 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31AFF1A016A for ; Wed, 29 Oct 2014 08:34:53 -0700 (PDT) Received: from vanmetedneysmbp.wireless.duke.local (west-4a-pat-1.oit.duke.edu [152.3.43.162]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 8B5A52781AC; Thu, 30 Oct 2014 00:34:49 +0900 (JST) Content-Type: multipart/alternative; boundary="Apple-Mail=_0A198B96-CF5B-4338-934F-C90E0B8014BB" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Rodney Van Meter In-Reply-To: <264EF2D3-F00F-4D3C-9576-D61879AE9D44@dell.com> Date: Wed, 29 Oct 2014 11:34:44 -0400 Message-Id: <7AA24002-0D95-4CD4-A379-7C242AA9B4C6@sfc.wide.ad.jp> References: <9FA67F6A-A730-46FC-925E-F16A1B686D73@sfc.wide.ad.jp> <7134F6D8-587F-4EBA-8E23-C088D8F1EA25@dell.com> <264EF2D3-F00F-4D3C-9576-D61879AE9D44@dell.com> To: Paul_Koning@Dell.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/hziHOPU3-CSNH7B-8XFpWJDnlU4 Cc: Rodney Van Meter , ipsec@ietf.org, kurosagi@sfc.wide.ad.jp, shigeya@wide.ad.jp Subject: Re: [IPsec] IPsec with QKD X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:34:56 -0000 --Apple-Mail=_0A198B96-CF5B-4338-934F-C90E0B8014BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Actually, we had considered that; the same adjustments to IKE can be = used for any out-of-band, asynchronous but ongoing supplier of key = material, with OTP keys via courier being the obvious example. We = decided when we started writing to focus on the QKD case, simply because = we felt that the broader approach (a) was more likely to result in more = discussion and a longer process within the WG, and (b) is less likely to = be readily identified, picked up and used by QKD implementers. When we initially began working on this, we also debated internally = about the right level of information to share between IPsec gateways; it = wasn=92t initially obvious that we could/should do it without more = QKD-specific support from IKE. Managing QKD is itself a big challenge. = We knew right away that we didn=92t want to get into any physical-level = discussions in the WG or include such negotations in the protocol, but = e.g. QKD depends on an authenticated classical channel as it operates, = to avoid a man in the middle attack, and it seemed plausible that we = might want to tie that channel to IPsec. In the end, we decided that = keeping things as separate as possible was probably wise, and in fact = our implementation turned out to be easiest that way. So, if there is interest within the WG in broadening the language, we = can do that, BUT: * We would need a decision about how to handle the Transform Type Values = and Payload Type Values, which is an IANA-relevant discussion; should = all out-of-band key agreement methods share a single identifier, or = should each one request a separate value? * Although we have succeeded in keeping a clean interface for this = particular case, we didn=92t feel like we knew enough about the range of = possible OOB key generation methods to state categorically that _they_ = would not need additional support within the protocol. =97Rod On Oct 29, 2014, at 11:03 AM, = wrote: > I wonder if this should be worded more generically. This is really = about an external key agreement mechanism. QKD is one such mechanism, = but it isn=92t clear to me that the machinery depends on this. > Suppose, for example, that you distributed copies of one-time pad = CDROMs to both locations, and used the key ID as offset in the = one-time-pad data. This is a completely different key agreement scheme = but it would seem to fit just as well. The important point is that = there is an external source of key material, which has the (assumed) = property that the key material is known to the two endpoints of the IKE = exchange, and to no other parties. >=20 > paul >=20 >>=20 >> On Oct 27, 2014, at 2:13 PM, Rodney Van Meter = wrote: >>=20 >>> ... >>> * We have just uploaded an -01 of the I-D we wrote, incorporating = feedback from several people, including Sean Turner, Sheila Frankel and = Alan Mink. >>> = http://datatracker.ietf.org/doc/draft-nagayama-ipsecme-ipsec-with-qkd/?inc= lude_text=3D1 >>=20 >=20 --Apple-Mail=_0A198B96-CF5B-4338-934F-C90E0B8014BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Actually, we had considered that; the same = adjustments to IKE can be used for any out-of-band, asynchronous but = ongoing supplier of key material, with OTP keys via courier being the = obvious example.  We decided when we started writing to focus on = the QKD case, simply because we felt that the broader approach (a) was = more likely to result in more discussion and a longer process within the = WG, and (b) is less likely to be readily identified, picked up and used = by QKD implementers.

When we initially began working = on this, we also debated internally about the right level of information = to share between IPsec gateways; it wasn=92t initially obvious that we = could/should do it without more QKD-specific support from IKE. =  Managing QKD is itself a big challenge.  We knew right away = that we didn=92t want to get into any physical-level discussions in the = WG or include such negotations in the protocol, but e.g. QKD depends on = an authenticated classical channel as it operates, to avoid a man in the = middle attack, and it seemed plausible that we might want to tie that = channel to IPsec.  In the end, we decided that keeping things as = separate as possible was probably wise, and in fact our implementation = turned out to be easiest that way.

So, if there = is interest within the WG in broadening the language, we can do that, = BUT:

* We would need a decision about how to = handle the Transform Type Values and Payload Type Values, which is an = IANA-relevant discussion; should all out-of-band key agreement methods = share a single identifier, or should each one request a separate = value?
* Although we have succeeded in keeping a clean = interface for this particular case, we didn=92t feel like we knew enough = about the range of possible OOB key generation methods to state = categorically that _they_ would not need additional support within the = protocol.

= =97Rod

On Oct 29, 2014, at 11:03 AM, <Paul_Koning@Dell.com> <Paul_Koning@Dell.com> = wrote:

I wonder if this should be worded more generically.  This is = really about an external key agreement mechanism.  QKD is one such = mechanism, but it isn=92t clear to me that the machinery depends on = this.
Suppose, for example, that you distributed copies of one-time pad = CDROMs to both locations, and used the key ID as offset in the = one-time-pad data.  This is a completely different key agreement = scheme but it would seem to fit just as well.  The important point is that there is an external source of key material, which has = the (assumed) property that the key material is known to the two = endpoints of the IKE exchange, and to no other parties.

paul


On Oct 27, 2014, at 2:13 PM, Rodney Van Meter <rdv@sfc.wide.ad.jp> = wrote:

...
* We have just uploaded an -01 of the I-D we wrote, incorporating = feedback from several people, including Sean Turner, Sheila Frankel and = Alan Mink.



= --Apple-Mail=_0A198B96-CF5B-4338-934F-C90E0B8014BB-- From nobody Wed Oct 29 10:58:03 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7BC1A872A for ; Wed, 29 Oct 2014 10:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jsYqqicZOFk for ; Wed, 29 Oct 2014 10:57:59 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4531A8762 for ; Wed, 29 Oct 2014 10:57:55 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ex7so2435938wid.2 for ; Wed, 29 Oct 2014 10:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=TLbRolK3Qx7jQZExPzZYJ3175X/yo7JJOzfcobLng9Q=; b=mYpnO2M/lGHYijIYnWrVDrRZk72AiZt5gGqcF4iS1w0WoSXngyzDJnTpNlhIl9PXjK hfq46fas/Qc1fJFR3JphqK0NmfOGM4t3YzXPJb5eVcmUlF4ps3Pokf4u/mLIru1XhVl8 asFAtGh0r6xS18gaozVflwd6K0cB2T0SsQQDZd8J7pMZYNZUZrEA/raDo1gsRsx5IhD/ 7YKrt+aqOCEy0RNwF4XjgnT0T07ZR4y2XzNvqfuZrY+bl/KufqFb2M8WOAqt15lRyYPq leWqhWryAGiP/3KRxfwGBxImc7Yl6OFFiakx2pGY10nySWpVKEDWF1uGT3/eYHzvwAlV fgZw== X-Received: by 10.180.13.11 with SMTP id d11mr38090879wic.19.1414605473817; Wed, 29 Oct 2014 10:57:53 -0700 (PDT) Received: from [10.2.0.122] (93-173-233-132.bb.netvision.net.il. [93.173.233.132]) by mx.google.com with ESMTPSA id j8sm19486293wib.10.2014.10.29.10.57.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 10:57:53 -0700 (PDT) Message-ID: <54512AA0.2040400@gmail.com> Date: Wed, 29 Oct 2014 19:57:52 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Justin Lai , ipsec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/EAOoGoPnjGgnU_fkJ3C75q71HCQ Subject: Re: [IPsec] RFC5723: Calculating auth value in IKE_AUTH during Session resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 17:58:01 -0000 Hi Justin, The IKE key material including SK_px is generated, and then AUTH is computed using SK_pi/SK_pr. This is independent on how the IKE SA was initiated when it was first set up. So in your example, the RSA private key is *not* used during resumption. This is in fact a benefit of session resumption, because private key operations are typically more expensive that computing a PRF. Thanks, Yaron On 10/29/2014 04:38 PM, Justin Lai wrote: > Hi, > > I am having some problem understanding how AUTH value is calculated > during IKE_AUTH when a session is resumed using RFC 5723. Is the > AUTH value calculation always going to be AUTH = prf(SK_px, ) > regardless of the auth type used? > > For example if the auth method used during login was RSA Digital Signature for > both client and gateway auth, then on session resumption, should the auth value > be computed using RSA private key as well or should the AUTH value be > computed using prf(SK_px, )? > > Thanks > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Wed Oct 29 15:38:34 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D751AC3A9 for ; Wed, 29 Oct 2014 15:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eEBV5rI1w9u for ; Wed, 29 Oct 2014 15:38:30 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3BF1A9174 for ; Wed, 29 Oct 2014 15:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10457; q=dns/txt; s=iport; t=1414622311; x=1415831911; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=G+CGGwu2sO009WQygFXe0defQXfU6uIDo3SjahWn8jw=; b=P7xwwPThNBTPHptJbcZ3EQzYhXXYWMntYa5ZM9MwT+ifrKl6G1ycnMvB l1VM4CSvWj5yanyOv3n/VV2p1QY3iQLJ7pnedxR6ivtUHxX4oIgw9x3IM okT1VhMil9eMQRCUTWwdo9K1VneLre5sLxykmUq5teLXSqoO/QukCHJ5Z c=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FACVrUVStJA2G/2dsb2JhbABTCYJrI1RYBM4bCodNAoEfFgEBAQEBfYQDAQEEAQEBawYFEAIBCA44AiULJQIEDgUOiDMBDMgWAQEBAQEBAQEBAQEBAQEBAQEBARmKdIVBBAkzGwcJhEIFkg2CEoFQaIcTgTE8gw6NPIQJggYYgVpsgQdBgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,280,1413244800"; d="p7s'?scan'208";a="91537046" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP; 29 Oct 2014 22:38:30 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9TMcTqZ008139 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 22:38:29 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 17:38:29 -0500 From: "Graham Bartlett (grbartle)" To: Yoav Nir Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-00.txt Thread-Index: AQHP8i/ndE20tkR+3keWIkzyL6SKVZxIAZQA Date: Wed, 29 Oct 2014 22:38:28 +0000 Message-ID: References: <20141027214823.13103.25135.idtracker@ietfa.amsl.com> In-Reply-To: <20141027214823.13103.25135.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.61.81.238] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3497467112_7791159" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/vBxaxWNvOgpSTcJrBXmowZzXGSI Cc: "ipsec@ietf.org" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 22:38:32 -0000 --B_3497467112_7791159 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Yoav I have some comments, which I have included below, I hope I have interoperated your document correctly. <<>> Within section 2 I feel the following (or similar should be added). RFC6989 defines a set of checks to be performed on received DH public values, the checks against a malformed DH value prevents a vulnerability when DH values are reused between peers. These checks can be very computationally expensive. The check is performed in SA_INIT when the DH value is received, in this case Stage #1 would increase in CPU power consumed. GB> from memory Yaron mentioned about the checks being performed when IKE_AUTHis received, RFC6989 states the checks should be performed when the public value is received, if the checks can be performed at IKE_AUTH then maybe add the following? Although this check could be delayed until the encrypted IKE_AUTH is received, should this check fail at Stage #2 the keys would never be derived. <<>> A strategy against DDoS has to rely on at least 4 components: 1. Hardening the half-open SA database by reducing retention time. 2. Hardening the half-open SA database by rate-limiting single IPs/ prefixes. 3. Guidance on what to do when an Authentication request fails to Decrypt. GB> I believe another check should be added between 2 and 3. (step 3 now become step 4) 3. Guidance on what to do when a number of DH Public Key value check fails (if RFC6989 checks are used). (the reason being if this was the case, you'd never get to # 3.) <<>> In the following you say that puzzle shouldn't be used, but then say about setting the level ? When there is no general DDoS attack, it is suggested that no Cookie or puzzles be used. At this point the only defensive measure is the monitoring, and setting a soft limit per peer IP or prefix. The soft limit can be set to 3-5, and the puzzle difficulty should be set to such a level (number of zero-bits) that all legitimate clients can handle it without degraded user experience. Maybe change to ? 'can be set to 3-5, and should the puzzle be used, the difficulty..' <<>> Supposing the the tunnels are established using EAP (see section 2.16 or RFC 7296) GB> 'or' should be 'of' <<>> I don't think the first thing is something we can deal with at the IKE level. It's probably better left to Intrusion Prevention System (IPS) technology. GB> I thought that we could add some words to how to help configure the IPS? (the following is an example of an idea I had).. Should an IPS or similar device be used when a VPN headend is under very heavy load when receiving many spoofed SA_INIT request. A strategy to note the IP TTL of IP addresses that leave 1/2 open connections and rate limit any requests that have a TTL at or below this value could be employed. <<>> Could you add the following to Section 7? As the puzzle is performed before the peer can reveal its identity, VPN headends can be deployed in a fashion where similar resourced clients are grouped in collections to connect to the same headend, this allows for puzzles of similar difficulty to be given to clients with similar processing power. Note that the idea of groups clients of similar processing power allows an attacker to prey on groups of low powered clients. <<>> I have some more ideas that I'll follow up soon. Many thanks On 27/10/2014 21:48, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the IP Security Maintenance and Extensions >Working Group of the IETF. > > Title : Protecting Internet Key Exchange (IKE) >Implementations from Distributed Denial of Service Attacks > Author : Yoav Nir > Filename : draft-ietf-ipsecme-ddos-protection-00.txt > Pages : 12 > Date : 2014-10-27 > >Abstract: > This document recommends implementation and configuration best > practices for Internet-connected IPsec Responders, to allow them to > resist Denial of Service and Distributed Denial of Service attacks. > Additionally, the document introduces a new mechanism called "Client > Puzzles" that help accomplish this task. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-00 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec --B_3497467112_7791159 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIOeAYJKoZIhvcNAQcCoIIOaTCCDmUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggw+MIIEpzCCA4+gAwIBAgIQZmBP5MZi1b5ckUheWh5wbTANBgkqhkiG9w0BAQUFADBU MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv YmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMB4XDTE0MDEyNTIyNDE0OFoXDTE2MDYw MzExMDA1OFowQDEbMBkGA1UEAwwSZ3JiYXJ0bGVAY2lzY28uY29tMSEwHwYJKoZIhvcNAQkB FhJncmJhcnRsZUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCq YhYxolKrFoPfXuZTQdAiQVFg14EvWwIEMyXxhfH2RiwOSJRSsUVmTNYG8HdeSf0JdzjAMh9p ODgxLC90Q1nbLyBqmEAKElWTasAnATKBCD7aLhce+25cznTT4FDpJsvvU2lZFPWXSLQm3bNR +mEDP6pd8zR1ItOKBlNmGtwypUUvi4KrKRPzx1cSgVTN0Xocj4fC5N8Rj3tOqOns+EHOX4Rw oy/rebHjQyv1cRr6FyGhRuz24hPv8mAGr/iF0cMphAsujaGKyAo+tA05K3nI0fdoeCx2wdEs vo8jIeeZVii07b3K9+VdJQmerVKJyMfQT6gLkyuassY/5aXlglNxAgMBAAGjggGHMIIBgzAO BgNVHQ8BAf8EBAMCBaAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYm aHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wHQYDVR0RBBYwFIESZ3Ji YXJ0bGVAY2lzY28uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3Nw ZXJzb25hbHNpZ24xZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDov L3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24xZzIuY3J0MB0G A1UdDgQWBBRBHvZ1Aur9AFGMEId10iH6yeUX3jAfBgNVHSMEGDAWgBTsrJjMJ3KTz1YyzSPH nY1FhfQiAzANBgkqhkiG9w0BAQUFAAOCAQEAdhq5YZv5ZCu0/HdQF1S3f+quesVc39HKv+Fe 2rmKuJcxfGOFZGpKhJDa1+sFeN/T+e2e6UJ0Yy90GLqi5U1fioD3XRhsFiVOh7CbJQESF2Xx U1bhdutZFh6Ythe28iRPY6HQjJ/7ke5IQBWvLnAbCIzgy0GgZB9Vj+a2z6bzmfR6KAuLaMqM vahvJ0w+DeHMEOVnVzCdZzHMaEOXZHw/uZj5/hGvkp2C0rH/LhGunfAPX12WhVQSsgxWJhaF 8D49Ymrt7PWBsLokx06/15XwY2ogBmfLmeN/WhMy5HUiLn3EnzwF+RK2MStCDpP5AWzdnrTR tM43+AJrHwoI7H+C9DCCBBYwggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUA MFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdS b290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcN MTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1z YTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGjx0+LH0uRqeZCHrYQ7KN3QuahfxY8 fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqDlin3HracDqMRgwrknWuFeqxh N2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQBhcaJA2ucABbUVTHDTxi 7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+OhtnAhrgzrsd4oAy qgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7upoxvV09Fsf7h DeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUdIAAw NDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAf BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7un yEtmt9Ia7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDu vg/OZ0gILDFIa9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVU m5V1tW3XuYNg6SbtcDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVg wb/j/kplOa13nshhc8zULVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5ui B8TZ0s327g44Ylc6dgKgYelNn9RLYjNETX8OIJZlr0tFYpcYrDCCA3UwggJdoAMCAQICCwQA AAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJv b3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7m mY3Oo+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsur HExwB6E9CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8G PIhpWypNxadUuGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounI Cjjr8iQTT3NUkxOFOhu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjI GSvRRqpI1mQq14M0/ywqwWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8 /UswDQYJKoZIhvcNAQEFBQADggEBANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16q EUi25Qijs8o9YU3TRgmzPsOg42NVG/K676054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeY BN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8suWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUM HaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRWMZXQZ4mFK/lspl1GnQyqguSZUd1wt9tW PWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY24GzBBzFH6SAbxUgyd4MiAod1mZV 4vxIySkmaeAxggH+MIIB+gIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzIC EGZgT+TGYtW+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgIBVf dE0OBpkIfXgb6G3AUmkxA3T0fmb3fWd8z9kZvrgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTQxMDI5MjIzODMyWjANBgkqhkiG9w0BAQEFAASCAQBh44rg ikzWAXgEIIJ59LQZjPtV7CQeoL0Q4nkZF9SIulde91rZlkWnyMXpQ+VfzyW0zWyUyTy6VmzQ Pr24NGVMMgGmIyCWMzHFzOnmf+l3gcQsgcuyYL/EAymj6W00P5Gv3bGAWgOiCAOO7MypLBsa J4v0JhcCJBwZGU+EniO1biyZQDZTs4Wt0WPVEg/FylQPPAU3XcNtvTFNWauZGreZ+f5LAehY vxnai+mDJRwvOTPCjpmWn+CaRN0fYUVWhS2BfW5dFPMLFyI4QQsTqy/mpuveRepvpvuVBZVN Q+BXvPcIcBO1cWTis/+Obfv3gi3NI9fGp6GkPhvjweO8lcTe --B_3497467112_7791159-- From nobody Fri Oct 31 05:13:08 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE441A8A16 for ; Fri, 31 Oct 2014 05:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.708 X-Spam-Level: X-Spam-Status: No, score=-95.708 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4qtC_GvdMaX for ; Fri, 31 Oct 2014 05:13:03 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C871A887B for ; Fri, 31 Oct 2014 05:13:03 -0700 (PDT) Received: from [192.168.0.2] (cpe-066-057-017-031.nc.res.rr.com [66.57.17.31]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 7C4342781C2; Fri, 31 Oct 2014 21:12:57 +0900 (JST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Rodney Van Meter In-Reply-To: Date: Fri, 31 Oct 2014 08:12:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <71AEFA9E-B761-411E-AAE1-E3DFCB93E517@sfc.wide.ad.jp> References: <9FA67F6A-A730-46FC-925E-F16A1B686D73@sfc.wide.ad.jp> <7134F6D8-587F-4EBA-8E23-C088D8F1EA25@dell.com> <264EF2D3-F00F-4D3C-9576-D61879AE9D44@dell.com> To: Greg Troxel X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/PDgfRbKhiw2K8X6IcI-Tl4DzB3A Cc: Rodney Van Meter , ipsec@ietf.org, kurosagi@sfc.wide.ad.jp, Paul_Koning@Dell.com, shigeya@wide.ad.jp Subject: Re: [IPsec] IPsec with QKD X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 12:13:06 -0000 On Oct 31, 2014, at 7:49 AM, Greg Troxel wrote: >=20 > I implemented using QKD material for IPsec (in 2002, if I can remember > the years right), which included an interface between QKD processing = and > racoon (on NetBSD) to include QKD bits in the Phase 2 hash. What's = been > published on that effort is: > http://dx.doi.org/10.1145/863955.863982 Yes, we=92re very familar with your work, the first in the world, as far = as I=92m aware! It was one of our inspirations, although our actual = implementation was done using QKD devices we borrowed from acquaintances = at NEC. I=92ve known Chip since about 2004. My memory fades already, = but when we began this project in 2008, if memory serves, we inquired = about simply using your code, but for some reason that wasn=92t = possible. I think at the time Chip felt like he was unable to release = it, but I can=92t remember the details. When we first wrote down what we had done (even before the I-D -00 was = published), Chip looked at our technical approach and endorsed it as = more flexible than what you guys had done, which I believe involved = borrowing some bits in existing headers rather than creating new payload = and transform types. I don=92t recall whether Chip asked you about it = directly at that time. I think Dave Pearson may have looked at it. FWIW, as long as we=92re talking history of projects, Sakane-san, one of = the key implementers of racoon2 if I have it right, kibbitzed with us a = bit on this project. =97Rod From nobody Fri Oct 31 09:00:07 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69681A8935 for ; Fri, 31 Oct 2014 04:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEh4936e-NAM for ; Fri, 31 Oct 2014 04:55:25 -0700 (PDT) Received: from fnord.ir.bbn.com (fnord.ir.bbn.com [192.1.100.210]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577771A8931 for ; Fri, 31 Oct 2014 04:55:25 -0700 (PDT) Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id B8AF8A6E4; Fri, 31 Oct 2014 07:55:24 -0400 (EDT) From: Greg Troxel To: References: <9FA67F6A-A730-46FC-925E-F16A1B686D73@sfc.wide.ad.jp> <7134F6D8-587F-4EBA-8E23-C088D8F1EA25@dell.com> <264EF2D3-F00F-4D3C-9576-D61879AE9D44@dell.com> OpenPGP: id=32611E25 X-Hashcash: 1:20:141031:kurosagi@sfc.wide.ad.jp::+4NUd+K2gRCkVG/K:000000000000000000000000000000000000001NFo X-Hashcash: 1:20:141031:ipsec@ietf.org::FNq1wfM708rjrmQ8:0001hVU X-Hashcash: 1:20:141031:rdv@sfc.wide.ad.jp::A4Nhb+lnbw5fFdp0:00000000000000000000000000000000000000000003iSZ X-Hashcash: 1:20:141031:paul_koning@dell.com::YH+OsS3l0je5U9a3:000000000000000000000000000000000000000000aun X-Hashcash: 1:20:141031:shigeya@wide.ad.jp::Z3sj9krZeXt5YL+Z:00000000000000000000000000000000000000000003Mk8 Date: Fri, 31 Oct 2014 07:55:24 -0400 In-Reply-To: <264EF2D3-F00F-4D3C-9576-D61879AE9D44@dell.com> (Paul Koning's message of "Wed, 29 Oct 2014 15:03:13 +0000") Message-ID: User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/_v86Qc9omas6F5iUDGqxQYtfMtg X-Mailman-Approved-At: Fri, 31 Oct 2014 09:00:06 -0700 Cc: rdv@sfc.wide.ad.jp, ipsec@ietf.org, kurosagi@sfc.wide.ad.jp, shigeya@wide.ad.jp Subject: Re: [IPsec] IPsec with QKD X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 11:55:27 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable writes: > I wonder if this should be worded more generically. This is really > about an external key agreement mechanism. QKD is one such mechanism, > but it isn=E2=80=99t clear to me that the machinery depends on this. > Suppose, for example, that you distributed copies of one-time pad > CDROMs to both locations, and used the key ID as offset in the > one-time-pad data. This is a completely different key agreement > scheme but it would seem to fit just as well. The important point is > that there is an external source of key material, which has the > (assumed) property that the key material is known to the two endpoints > of the IKE exchange, and to no other parties. I agree that just having an external keying material abstraction makes sense. In particular, thinking about it in a larger context is likely to force clarity on issues of how external keying material is named and numbered, and how to deal with the possibility that bits which should match might not. There are multiple ways to use external material: as OTP, directly as symmettric keys and by including it in the phase 2 hash. We implemented the first and third of these around 2002, and what's been published about that system is at http://dx.doi.org/10.1145/863955.863982 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRTeKwACgkQ+vesoDJhHiVHPACfTH6DiNZqtcln77Ev+guwC3hL 0FwAoIB+jIdaFMwSfg4E8ttaVjuIoyXe =cFwe -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 31 14:05:50 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99081A1B5D for ; Fri, 31 Oct 2014 14:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IcynS19guom for ; Fri, 31 Oct 2014 14:05:44 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56551A1B60 for ; Fri, 31 Oct 2014 14:05:36 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id 10so6744706lbg.36 for ; Fri, 31 Oct 2014 14:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rJ1rbMKHMKlXa2dnDBVwOw/PCM1TQyUCCLgfZ8Nhbso=; b=JIA6O8cKXLNEpugJVqKFT/LzjY+aOEiznG4mix8jCQhb4Q3MYZE3+UcGnC9rDdAIrM bp3pB/cksoo2NY0F7VONLyVyg++RWDdHszoiobeQ1hF9KLM8bDzOdNl5WYEYz+0UVm18 9X/1AveSkbDUiMAwKECqL4ToW7OLHGaeJQ4ACAr/t90J1ZdFYgcp6TIZPZzaio/I9c6L 2A1EpU0929svAj0heq4SjzBOt/WZ4zeEyomZlsMltll8oER3tK7keuoIPuobKDhNZfNp Mwf0uQC1nhuWaX5vK6yPychuto1WJ3vhKdrJbI1swes6nHSxV8JZrTtxfnGQkwgiyiS2 BmlQ== MIME-Version: 1.0 X-Received: by 10.112.167.200 with SMTP id zq8mr2437041lbb.61.1414789534877; Fri, 31 Oct 2014 14:05:34 -0700 (PDT) Received: by 10.112.95.17 with HTTP; Fri, 31 Oct 2014 14:05:34 -0700 (PDT) Date: Fri, 31 Oct 2014 17:05:34 -0400 Message-ID: From: Kathleen Moriarty To: "ipsec@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/F85NJDBzHdSuyYjNgWD1X8D5tXE Subject: [IPsec] Charter review X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 21:05:47 -0000 Hi, The chairs provided text for an updated charter in line with the newly adopted working group items. The recharter text has been posted and I'd like to give the WG a little time to comment prior to adding this to a telechat for review. Here is a link: http://datatracker.ietf.org/doc/charter-ietf-ipsecme/ Thanks. -- Best regards, Kathleen From nobody Fri Oct 31 14:14:27 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C031A1BA2 for ; Fri, 31 Oct 2014 14:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMKvUdnJMIK6 for ; Fri, 31 Oct 2014 14:13:47 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B528B1A1B8A for ; Fri, 31 Oct 2014 14:13:45 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 20AC480055; Fri, 31 Oct 2014 17:13:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1414790007; bh=rxT63MTKHkUJgWfP3CYSVB9Oja4ADa5eAESKEo1rlUM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DiHug7YICceJpNNgOQH6PyFyOavYp0xgnMNl41S3vhYfMZg4KnjUghT8Ni1slwIzG xJ0unezp5l5yWTKTSEJ/Y02wp6tUvjxjFa7MauyIBjd525VvQk1hGBmescfJ51yRSP LarxLOr4BAyvDhmoewSLSDztKlkvU+uGKB+c3X4E= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s9VLDQwB001336; Fri, 31 Oct 2014 17:13:26 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 31 Oct 2014 17:13:26 -0400 (EDT) From: Paul Wouters To: Kathleen Moriarty In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/XaB_amL9NyOD4ZSXtnIc2nSYoFU Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Charter review X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 21:13:56 -0000 On Fri, 31 Oct 2014, Kathleen Moriarty wrote: > The chairs provided text for an updated charter in line with the newly > adopted working group items. The recharter text has been posted and > I'd like to give the WG a little time to comment prior to adding this > to a telechat for review. > > Here is a link: > > http://datatracker.ietf.org/doc/charter-ietf-ipsecme/ There is interest in adapting the IKE protocol for opportunistic use cases, by allowing one or both endpoints of the exchange to remain unauthenticated. The group will extend the protocol to support these use cases. The solution should be in line with current best practices, including channel binding and possible formal protocol security proofs. I don't think there was agreement on channel binding? It's a bit of an old wound, since some believe BTNS failed because of channel binding requirements (requiring kernel code changes) Paul From nobody Fri Oct 31 15:53:48 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5A01A6FB0 for ; Fri, 31 Oct 2014 15:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq70Lor9hurn for ; Fri, 31 Oct 2014 15:53:44 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E3C71A854D for ; Fri, 31 Oct 2014 15:53:44 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-34.dsl.dynamic.fusionbroadband.com [50.0.66.34]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s9VMreZP010907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Oct 2014 15:53:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-0-66-34.dsl.dynamic.fusionbroadband.com [50.0.66.34] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Paul Hoffman In-Reply-To: Date: Fri, 31 Oct 2014 15:53:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Paul Wouters X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/7JW-tN4It8Wb1tb0rshsqGqFnyk Cc: "ipsec@ietf.org" , Kathleen Moriarty Subject: Re: [IPsec] Charter review X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 22:53:46 -0000 On Oct 31, 2014, at 2:13 PM, Paul Wouters wrote: >=20 > On Fri, 31 Oct 2014, Kathleen Moriarty wrote: >=20 >> The chairs provided text for an updated charter in line with the = newly >> adopted working group items. The recharter text has been posted and >> I'd like to give the WG a little time to comment prior to adding this >> to a telechat for review. >>=20 >> Here is a link: >>=20 >> http://datatracker.ietf.org/doc/charter-ietf-ipsecme/ >=20 >=20 > There is interest in adapting the IKE protocol for opportunistic = use cases, by > allowing one or both endpoints of the exchange to remain = unauthenticated. The > group will extend the protocol to support these use cases. The = solution should > be in line with current best practices, including channel = binding and possible > formal protocol security proofs. >=20 > I don't think there was agreement on channel binding? It's a bit of an > old wound, since some believe BTNS failed because of channel binding > requirements (requiring kernel code changes) There was not agreement that the eventual solution needs channel = binding, but there was interest in us trying. If we fail at getting = channel binding and/or formal security proofs, that's OK, but it's worth = the effort. --Paul Hoffman=