From anova@cisco.com Mon Mar 4 05:58:01 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF6421F8A8B for ; Mon, 4 Mar 2013 05:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WM5KOcT+yJTv for ; Mon, 4 Mar 2013 05:58:00 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF4021F8A8A for ; Mon, 4 Mar 2013 05:57:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7194; q=dns/txt; s=iport; t=1362405480; x=1363615080; h=from:to:subject:date:message-id:mime-version; bh=Ce5mVdWDOIgko35Ai4YvTwtx7VD72bK6iBniZM+GbIw=; b=fq+IdhQEPA0kTxKh/Okn+6BHECEqU3h1/tf3RPKNn9cZfl8c4rQaMSQr cl6EDE8chP8bgNTOtKFGTq2u7bZr+taWvEHn/ks8uc+XWiMtRdDty0QO7 V1R50JL8za352pw6TzULbcMJiK5zYpj+H8B3eK2f97r/EFqhFzqb1ahpL g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAM+mNFGtJV2b/2dsb2JhbABFgkPACoEBFnOCIQEELT4gASpWJgEEChERh3qmbKBHjlyDF2EDpzKDCIIn X-IronPort-AV: E=Sophos;i="4.84,779,1355097600"; d="scan'208,217";a="183447025" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 04 Mar 2013 13:57:59 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r24Dvxmk027830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 4 Mar 2013 13:57:59 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Mon, 4 Mar 2013 07:57:59 -0600 From: "Anoop V A (anova)" To: "ipsec@ietf.org" Thread-Topic: Regarding ISAKMP SA lifetime negotiation. Thread-Index: Ac4Y4ESuGmhSbq0+TBy5np9wzLbTAQ== Date: Mon, 4 Mar 2013 13:57:58 +0000 Message-ID: <0E86FFD429E5FA4A97B86698F6C32AF81C271A91@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.59] Content-Type: multipart/alternative; boundary="_000_0E86FFD429E5FA4A97B86698F6C32AF81C271A91xmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [IPsec] Regarding ISAKMP SA lifetime negotiation. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 13:58:01 -0000 --_000_0E86FFD429E5FA4A97B86698F6C32AF81C271A91xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello experts, I have a generic doubt regarding the ISAKMP SA(phase 1) life time negoti= ation. My query is can we agree up on the ISAKMP life time in the first t= wo messages of MM or AM. What I want to know is - the life time is sent as an proposal attribute in= the first two messages of Main mode and aggressive mode. We are not negoti= ating the parameter so if the responder is having a less life time value co= nfigured - then can we transfer this info in the MM2 or AM2 message from th= e responder along with the negotiated proposal attributes. Basically I am t= rying to change the life time attribute sent by the initiator - in this sce= nario. We have the responder life time notify mechanism as per the draft (draft-ie= tf-ipsec-ike-lifetime-00), but the separate notify messages are not reliabl= e in IKEv1(Uni directional) In short my questions are: 1. Can we send the responder life time notification in MM6 or AM2 mes= sage from the responder? 2. Or can we alter the life time attribute of the ISAKMP SA proposal = offer?( Is this considers as a violation of the RFC) Thanks Anoop --_000_0E86FFD429E5FA4A97B86698F6C32AF81C271A91xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hello experts,

 

   I have a generic doubt regarding the IS= AKMP SA(phase 1) life time negotiation. My  query is can we agree up o= n the  ISAKMP life time in the first two messages of MM or AM.

 

What I want to know is  - the life time is sent= as an proposal attribute in the first two messages of Main mode and aggres= sive mode. We are not negotiating the parameter so if the responder is havi= ng a less life time value configured – then can we transfer this info in the MM2 or AM2 message from the responde= r along with the negotiated proposal attributes. Basically I am trying to c= hange the life time attribute sent by the initiator – in this scenari= o.

 

We have the responder life time notify mechanism as = per the draft (draft-ietf-ipsec-ike-lifetime-00), but the separate notify m= essages are not reliable in IKEv1(Uni directional)

 

In short my questions are:

 

1.     &= nbsp; Can we send the responder life time notification in= MM6 or AM2 message from the responder?

2.     &= nbsp; Or can we alter the life time attribute of the ISAK= MP SA proposal offer?( Is this considers as  a violation of the RFC)

 

Thanks

Anoop

--_000_0E86FFD429E5FA4A97B86698F6C32AF81C271A91xmbrcdx04ciscoc_-- From kivinen@iki.fi Mon Mar 4 06:31:54 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D1F21F8967 for ; Mon, 4 Mar 2013 06:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPi7-mBT3dqI for ; Mon, 4 Mar 2013 06:31:54 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id CFC4821F8921 for ; Mon, 4 Mar 2013 06:31:53 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r24EVi9x007617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Mar 2013 16:31:44 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r24EViRv013345; Mon, 4 Mar 2013 16:31:44 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20788.45136.1741.27834@fireball.kivinen.iki.fi> Date: Mon, 4 Mar 2013 16:31:44 +0200 From: Tero Kivinen To: "Anoop V A (anova)" In-Reply-To: <0E86FFD429E5FA4A97B86698F6C32AF81C271A91@xmb-rcd-x04.cisco.com> References: <0E86FFD429E5FA4A97B86698F6C32AF81C271A91@xmb-rcd-x04.cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 15 min Cc: "ipsec@ietf.org" Subject: [IPsec] Regarding ISAKMP SA lifetime negotiation. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 14:31:54 -0000 Anoop V A (anova) writes: > > Hello experts, > > I have a generic doubt regarding the ISAKMP SA(phase 1) life time > negotiation. My query is can we agree up on the ISAKMP life > time in the first two messages of MM or AM. > > What I want to know is - the life time is sent as an proposal > attribute in the first two messages of Main mode and aggressive > mode. We are not negotiating the parameter so if the responder is > having a less life time value configured - then can we transfer this > info in the MM2 or AM2 message from the responder along with the > negotiated proposal attributes. Basically I am trying to change the > life time attribute sent by the initiator - in this scenario. Anything extra (notifications etc) you send inside the main mode or agressive mode packets are not authenticated, so sending responder life time notifications is not good idea (and the other end will simply ignore it). > We have the responder life time notify mechanism as per the draft > (draft-ietf-ipsec-ike-lifetime-00), but the separate notify messages > are not reliable in IKEv1(Uni directional) That is expired very old draft that did not get forward, there is no point of implementing that... > In short my questions are: > > 1. Can we send the responder life time notification in MM6 or > AM2 message from the responder? You can, but most likely all implementations will ignore them, and if any implementation does not ignore them, that opens attack where attacker can shorten the lifetime at will by just adding such notification. > 2. Or can we alter the life time attribute of the ISAKMP SA > proposal offer?( Is this considers as a violation of the > RFC) That is considered violation of the RFC, thus all complient implemnetations will reject the proposal. RFC2408 section 4.2 Security Association Establishment last paragraph: The initiator MUST verify that the Security Association payload received from the responder matches one of the proposals sent initially. Easy answer to all of your questions is to NOT use the protocol that was obsoleted more than 7 years ago (IKEv1 was obsoleted by IKEv2 in 2005), and instead start to use current version of the protocol i.e IKEv2, which already solves those problem (the notifications are authenticated, the lifetimes are removed and moved to local matter, the informational exchanges are reliable etc). -- kivinen@iki.fi From ynir@checkpoint.com Mon Mar 4 08:00:42 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D5121F869C for ; Mon, 4 Mar 2013 08:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zE3tR0ixp0un for ; Mon, 4 Mar 2013 08:00:41 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 81B6021F8C1A for ; Mon, 4 Mar 2013 08:00:34 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r24G0MVp015351; Mon, 4 Mar 2013 18:00:26 +0200 X-CheckPoint: {5134C4CB-19-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.95]) with mapi id 14.02.0342.003; Mon, 4 Mar 2013 18:00:22 +0200 From: Yoav Nir To: Tero Kivinen Thread-Topic: [IPsec] Regarding ISAKMP SA lifetime negotiation. Thread-Index: Ac4Y4ESuGmhSbq0+TBy5np9wzLbTAf//5+wAgAAYwoA= Date: Mon, 4 Mar 2013 16:00:22 +0000 Message-ID: References: <0E86FFD429E5FA4A97B86698F6C32AF81C271A91@xmb-rcd-x04.cisco.com> <20788.45136.1741.27834@fireball.kivinen.iki.fi> In-Reply-To: <20788.45136.1741.27834@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <1B7895C990038D419EA6EB476B0FFC46@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "Anoop V A \(anova\)" Subject: Re: [IPsec] Regarding ISAKMP SA lifetime negotiation. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 16:00:42 -0000 On Mar 4, 2013, at 4:31 PM, Tero Kivinen wrote: > Anoop V A (anova) writes: >>=20 >> Hello experts, >>=20 >> I have a generic doubt regarding the ISAKMP SA(phase 1) life time >> negotiation. My query is can we agree up on the ISAKMP life >> time in the first two messages of MM or AM.=20 >>=20 >> What I want to know is - the life time is sent as an proposal >> attribute in the first two messages of Main mode and aggressive >> mode. We are not negotiating the parameter so if the responder is >> having a less life time value configured - then can we transfer this >> info in the MM2 or AM2 message from the responder along with the >> negotiated proposal attributes. Basically I am trying to change the >> life time attribute sent by the initiator - in this scenario.=20 >=20 > Anything extra (notifications etc) you send inside the main mode or > agressive mode packets are not authenticated, so sending responder > life time notifications is not good idea (and the other end will > simply ignore it). This is true for MM2, but not for MM6. MM6 is encrypted and authenticated, = so the peer can and should (if they implemented the draft) use it. >=20 >> We have the responder life time notify mechanism as per the draft >> (draft-ietf-ipsec-ike-lifetime-00), but the separate notify messages >> are not reliable in IKEv1(Uni directional) >=20 > That is expired very old draft that did not get forward, there is no > point of implementing that...=20 It makes sense for working with implementations where you can't configure s= uch parameters, like VPN clients. Sadly, none of the generic IKEv1-using cl= ients (like the L2TP clients) seem to support this draft. >> In short my questions are: >>=20 >> 1. Can we send the responder life time notification in MM6 or >> AM2 message from the responder? >=20 > You can, but most likely all implementations will ignore them, and > if any implementation does not ignore them, that opens attack where > attacker can shorten the lifetime at will by just adding such > notification.=20 MM6 and AM2 are protected. >=20 >> 2. Or can we alter the life time attribute of the ISAKMP SA >> proposal offer?( Is this considers as a violation of the >> RFC) >=20 > That is considered violation of the RFC, thus all complient > implemnetations will reject the proposal. RFC2408 section 4.2 Security > Association Establishment last paragraph: >=20 > The > initiator MUST verify that the Security Association payload received > from the responder matches one of the proposals sent initially. >=20 > Easy answer to all of your questions is to NOT use the protocol that > was obsoleted more than 7 years ago (IKEv1 was obsoleted by IKEv2 in > 2005), and instead start to use current version of the protocol i.e > IKEv2, which already solves those problem (the notifications are > authenticated, the lifetimes are removed and moved to local matter, > the informational exchanges are reliable etc). Now that I agree with. This draft addresses one deficiency in IKEv1. The re= ason to support IKEv1 today is to support legacy implementations. I don't t= hink anyone is adding this feature now to legacy implementations. So yes, <= hat type=3D"vendor"> Check Point code supports it, but it's better t= o use IKEv2 where interoperability with different configured lifetimes has = been shown to work. Yoav From anova@cisco.com Mon Mar 4 08:11:58 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD9D21F84E8 for ; Mon, 4 Mar 2013 08:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7z7IS8cj8Rh for ; Mon, 4 Mar 2013 08:11:57 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 620FE21F8491 for ; Mon, 4 Mar 2013 08:11:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4540; q=dns/txt; s=iport; t=1362413517; x=1363623117; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GD0SPZSYYfURLFPa0H89jKC77BJ5qCsqMm5J0GhnGHo=; b=I//kVz4Ue7EdDza11fiUglp2zAOn07NvSJGSDrUtuHbbkUxDeOdWKuHO lI3goOobary/gH4LkURyMlRc0btrEm2ig5MB6zDzZuFyTNYwqmCGm9/2M xQMaa3rbmRrp4i8TWlB1YiDT2DY0Bxyv2wV4VmurJAJrLbJDXI97Lga+A k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFrGNFGtJXHB/2dsb2JhbABFwk2BAhZzgh8BAQEDAToxDgUHBAIBCA4DBAEBCxQJBzIUCQgBAQQBCQQFCBECh3IGxU6OXCYLBwaCWWEDpzKDCIIn X-IronPort-AV: E=Sophos;i="4.84,780,1355097600"; d="scan'208";a="183536238" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 04 Mar 2013 16:11:57 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r24GBuii023815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Mar 2013 16:11:56 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Mon, 4 Mar 2013 10:11:56 -0600 From: "Anoop V A (anova)" To: Yoav Nir , Tero Kivinen Thread-Topic: [IPsec] Regarding ISAKMP SA lifetime negotiation. Thread-Index: Ac4Y4ESuGmhSbq0+TBy5np9wzLbTAf//5+wAgAAYwoD//92EoA== Date: Mon, 4 Mar 2013 16:11:56 +0000 Message-ID: <0E86FFD429E5FA4A97B86698F6C32AF81C271B6F@xmb-rcd-x04.cisco.com> References: <0E86FFD429E5FA4A97B86698F6C32AF81C271A91@xmb-rcd-x04.cisco.com> <20788.45136.1741.27834@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.68.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Regarding ISAKMP SA lifetime negotiation. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 16:11:58 -0000 Hi Yoav/Kivinen Thanks a lot for your quick response. As Yoav said - this is for the = some legacy solution support - there in some strange situation we are endi= ng up with different lifetime in the boxes, and creating some issues. So now as to add to the same question - If we are sending the extra IKE responder life time notification in MM6 or= AM2 - since the peer AUTHENTICATION data is also available in these messag= es - can we overcome this situation. We can avoid attack by changing the li= fe time only if the authentication is successful. I understand may be other implementation will avoid this extra notify - but= is there any violation in sending this extra notify in these messages? Thanks Anoop -----Original Message----- From: Yoav Nir [mailto:ynir@checkpoint.com]=20 Sent: Monday, March 04, 2013 9:30 PM To: Tero Kivinen Cc: Anoop V A (anova); ipsec@ietf.org Subject: Re: [IPsec] Regarding ISAKMP SA lifetime negotiation. On Mar 4, 2013, at 4:31 PM, Tero Kivinen wrote: > Anoop V A (anova) writes: >>=20 >> Hello experts, >>=20 >> I have a generic doubt regarding the ISAKMP SA(phase 1) life time >> negotiation. My query is can we agree up on the ISAKMP life >> time in the first two messages of MM or AM.=20 >>=20 >> What I want to know is - the life time is sent as an proposal=20 >> attribute in the first two messages of Main mode and aggressive mode.=20 >> We are not negotiating the parameter so if the responder is having a=20 >> less life time value configured - then can we transfer this info in=20 >> the MM2 or AM2 message from the responder along with the negotiated=20 >> proposal attributes. Basically I am trying to change the life time=20 >> attribute sent by the initiator - in this scenario. >=20 > Anything extra (notifications etc) you send inside the main mode or=20 > agressive mode packets are not authenticated, so sending responder=20 > life time notifications is not good idea (and the other end will=20 > simply ignore it). This is true for MM2, but not for MM6. MM6 is encrypted and authenticated, = so the peer can and should (if they implemented the draft) use it. >=20 >> We have the responder life time notify mechanism as per the draft=20 >> (draft-ietf-ipsec-ike-lifetime-00), but the separate notify messages=20 >> are not reliable in IKEv1(Uni directional) >=20 > That is expired very old draft that did not get forward, there is no=20 > point of implementing that... It makes sense for working with implementations where you can't configure s= uch parameters, like VPN clients. Sadly, none of the generic IKEv1-using cl= ients (like the L2TP clients) seem to support this draft. >> In short my questions are: >>=20 >> 1. Can we send the responder life time notification in MM6 or >> AM2 message from the responder? >=20 > You can, but most likely all implementations will ignore them, and if=20 > any implementation does not ignore them, that opens attack where=20 > attacker can shorten the lifetime at will by just adding such=20 > notification. MM6 and AM2 are protected. >=20 >> 2. Or can we alter the life time attribute of the ISAKMP SA >> proposal offer?( Is this considers as a violation of the >> RFC) >=20 > That is considered violation of the RFC, thus all complient=20 > implemnetations will reject the proposal. RFC2408 section 4.2 Security=20 > Association Establishment last paragraph: >=20 > The > initiator MUST verify that the Security Association payload received > from the responder matches one of the proposals sent initially. >=20 > Easy answer to all of your questions is to NOT use the protocol that=20 > was obsoleted more than 7 years ago (IKEv1 was obsoleted by IKEv2 in=20 > 2005), and instead start to use current version of the protocol i.e=20 > IKEv2, which already solves those problem (the notifications are=20 > authenticated, the lifetimes are removed and moved to local matter,=20 > the informational exchanges are reliable etc). Now that I agree with. This draft addresses one deficiency in IKEv1. The re= ason to support IKEv1 today is to support legacy implementations. I don't t= hink anyone is adding this feature now to legacy implementations. So yes, <= hat type=3D"vendor"> Check Point code supports it, but it's better t= o use IKEv2 where interoperability with different configured lifetimes has = been shown to work. Yoav From paul.hoffman@vpnc.org Mon Mar 4 12:18:52 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC4C21F8925 for ; Mon, 4 Mar 2013 12:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1z234lPR7B0b for ; Mon, 4 Mar 2013 12:18:52 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 43C7C21F862E for ; Mon, 4 Mar 2013 12:18:52 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r24KIoC8049532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 4 Mar 2013 13:18:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9B39E42C-4C94-4530-AF28-A82BD60B0038@vpnc.org> Date: Mon, 4 Mar 2013 12:18:50 -0800 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [IPsec] Agenda for Orlando X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 20:18:53 -0000 Greetings again. Here is the proposed agenda for Orlando. Let Yaron and = I know if you have any changes you want. --Paul Hoffman IPsecME WG IETF 86, Orlando Tuesday, March 12, 0900-1020 (80 minutes) Auto Discovery VPN Problem Statement and Requirements - 15 mins http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem A TCP transport for the Internet Key Exchange - 20 mins http://tools.ietf.org/html/draft-ietf-ipsecme-ike-tcp Additional Diffie-Hellman Tests for IKEv2 - 5 mins http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks Signature Authentication in IKEv2 - 10 mins http://tools.ietf.org/html/draft-kivinen-ipsecme-signature-auth More Raw Public Keys for IKEv2 - 10 mins http://tools.ietf.org/html/draft-kivinen-ipsecme-oob-pubkey Cryptographic Algorithm Implementation Requirements and Usage Guidance = for ESP and AH - 15 mins Not-quite-submitted draft simple VPN solution using Multi-point Security Association - 5 mins http://tools.ietf.org/html/draft-yamaya-ipsecme-mpsa If time permits: draft-gundavelli-ipsecme-3gpp-ims-options - 5 mins From paul.hoffman@vpnc.org Mon Mar 4 14:33:47 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E32211E80A2 for ; Mon, 4 Mar 2013 14:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+rLjMRCMJKC for ; Mon, 4 Mar 2013 14:33:46 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8178F21F868E for ; Mon, 4 Mar 2013 14:33:46 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r24MXjcU054385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 4 Mar 2013 15:33:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Mar 2013 14:33:44 -0800 References: <20130304192746.18520.60832.idtracker@ietfa.amsl.com> To: IPsecme WG Message-Id: <2EF1A5D1-EE77-4B0B-A185-15B5CAD2CB21@vpnc.org> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [IPsec] Fwd: Document Action: 'Brainpool Elliptic Curves for the IKE Group Description Registry' to Informational RFC (draft-harkins-brainpool-ike-groups-04.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 22:33:47 -0000 Begin forwarded message: > From: The IESG > Subject: Document Action: 'Brainpool Elliptic Curves for the IKE Group = Description Registry' to Informational RFC = (draft-harkins-brainpool-ike-groups-04.txt) > Date: March 4, 2013 11:27:46 AM PST > To: IETF-Announce > Cc: RFC Editor >=20 > The IESG has approved the following document: > - 'Brainpool Elliptic Curves for the IKE Group Description Registry' > (draft-harkins-brainpool-ike-groups-04.txt) as Informational RFC >=20 > This document has been reviewed in the IETF but is not the product of = an > IETF Working Group. >=20 > The IESG contact person is Sean Turner. >=20 > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-harkins-brainpool-ike-groups/ >=20 >=20 >=20 >=20 > Technical Summary >=20 > The draft allocates code points for four new elliptic curve domain > parameter sets (ECC Brainpool curves from RFC 5639) > over finite prime fields into a registry that was established by the = IKEv1 > (https://www.iana.org/assignments/ipsec-registry) but is used by other > protocols (IEEE 802.11aa, IEEE 802.11s, RFC 5931).=20 >=20 > Working Group Summary >=20 > The draft was discussed quite controversially on the WG mailing list. > There are persons in the WG that strongly feel > that no further code points should be defined for IKEv1 because the > protocol has been deprecated long ago (by RFC 4306). > Other persons in the WG argued that IKEv1 is still widely used in > practice and, furthermore, other code points have been > assigned previously to the same name space after IKEv1 was obsoleted. = No > consensus could be achieved on this topic. On > the other hand, the ADs received an informal liaison statement from = IEEE > 802.11 > (https://datatracker.ietf.org/liaison/1181/) requesting code point > assignments for these curves in the IKEv1 registry. > IEEE standards 802.11aa and 802.11s are using this name space of the > IKEv1 registry, and these specs are apparently not > up for change until 2015. The matter was discussed at the SAAG meeting > among the ADs and the WG members present and it > was decided to publish an internet-draft that requests these code = points > but also requires IANA to add a note that they > are not for IKEv1. In the WG discussion following its publication, > concerns were uttered that the note won't be enough > to stop people asking for IKEv1 products to support these new code > points and to prevent implementers to use them for > IKEv1. On the other hand, it was expressed that requiring the IEEE = specs > to point to another (new) registry is probably > not possible due to their publishing cycle. Alternative solutions were > discussed, e.g. to include in the registry only a > link pointing to another registry where the actual values are listed. > Eventually, the approach of the draft, i.e. to > include a note "not for IKE" in the registry, was widely considered = the > best way forward. >=20 > After some comments on earlier versions, an announcement of a revised > draft on the ipsecme mailing list did not result > in any further comments. >=20 > There was agreement that the draft shall not be a WG document.=20 >=20 > Document Quality >=20 > Some specific comments of Tim Polk were accommodated in a revision.=20 >=20 > Personnel >=20 > The Document Shepherd is Johannes Merkle, the sponsoring AD is Sean = Turner.=20 >=20 From kivinen@iki.fi Tue Mar 5 02:41:00 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762F021F8887 for ; Tue, 5 Mar 2013 02:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_36=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMmdFR1zVKYV for ; Tue, 5 Mar 2013 02:41:00 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id A4CBE21F87BA for ; Tue, 5 Mar 2013 02:40:59 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r25AebqF000594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Mar 2013 12:40:37 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r25Aeakx007323; Tue, 5 Mar 2013 12:40:36 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20789.52132.677614.30811@fireball.kivinen.iki.fi> Date: Tue, 5 Mar 2013 12:40:36 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <0E86FFD429E5FA4A97B86698F6C32AF81C271A91@xmb-rcd-x04.cisco.com> <20788.45136.1741.27834@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 16 min Cc: "ipsec@ietf.org" , "Anoop V A \(anova\)" Subject: Re: [IPsec] Regarding ISAKMP SA lifetime negotiation. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 10:41:00 -0000 Yoav Nir writes: > > Anything extra (notifications etc) you send inside the main mode or > > agressive mode packets are not authenticated, so sending responder > > life time notifications is not good idea (and the other end will > > simply ignore it). > > This is true for MM2, but not for MM6. MM6 is encrypted and > authenticated, so the peer can and should (if they implemented the > draft) use it. MM6 is encrypted, but not authenticated, except for certain parts inside the packet. The MM5/MM6 do have SIG (certificates)/HASH (pre-shared keys) payload, but that only covers certain parts: HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b ) So if original MM5/MM6 has notification payload and attacker can guess where it is (not very hard), he can modify it (even when it is encrypted). This is one of the things we did fix in the IKEv2, and thats why IKEv2 do MAC all of the payloads, and the authentication hash do include the whole IKE_SA_INIT packet so it also gets authenticated. -- kivinen@iki.fi From kivinen@iki.fi Tue Mar 5 03:34:22 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537AA21F8923 for ; Tue, 5 Mar 2013 03:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwZDNvhPNNlk for ; Tue, 5 Mar 2013 03:34:22 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8A89B21F88E6 for ; Tue, 5 Mar 2013 03:34:21 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r25BY9OG009590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Mar 2013 13:34:09 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r25BY8p9018906; Tue, 5 Mar 2013 13:34:08 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20789.55344.544698.606624@fireball.kivinen.iki.fi> Date: Tue, 5 Mar 2013 13:34:08 +0200 From: Tero Kivinen To: "Anoop V A (anova)" In-Reply-To: <0E86FFD429E5FA4A97B86698F6C32AF81C271B6F@xmb-rcd-x04.cisco.com> References: <0E86FFD429E5FA4A97B86698F6C32AF81C271A91@xmb-rcd-x04.cisco.com> <20788.45136.1741.27834@fireball.kivinen.iki.fi> <0E86FFD429E5FA4A97B86698F6C32AF81C271B6F@xmb-rcd-x04.cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 5 min Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] Regarding ISAKMP SA lifetime negotiation. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 11:34:22 -0000 Anoop V A (anova) writes: > If we are sending the extra IKE responder life time notification in > MM6 or AM2 - since the peer AUTHENTICATION data is also available > in these messages - can we overcome this situation. We can avoid > attack by changing the life time only if the authentication is > successful. As I pointed out earlier, attacker can MODIFY the notification data, so they can change the life time stored inside the notification data (there are some difficulties there, but lets not go to them). On the other hand you would never accept any lifetime that would not be accordingly to your own policy anyways, so this attack isn't that effective in this case, as attacker can only change lifetime to something that you would otherwise accept. So in worst case you are in the same situation you were without this notification. > I understand may be other implementation will avoid this extra > notify - but is there any violation in sending this extra notify in > these messages? Most likely they will ignore the extra notify, but to be safe it might be better to add vendor id payloads and only send notify if the other end is sending known vendor id. There are some quite bad IKEv1 implementations out there, and I would not even try to guess what they might do when they get extra notification payloads. -- kivinen@iki.fi From paul@cypherpunks.ca Wed Mar 6 09:09:26 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CED21F8AE7 for ; Wed, 6 Mar 2013 09:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[AWL=1.209, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cb1z1o0cPRb for ; Wed, 6 Mar 2013 09:09:26 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 48FC721F8AC2 for ; Wed, 6 Mar 2013 09:09:26 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZLhKG17D5z9dQ; Wed, 6 Mar 2013 12:09:22 -0500 (EST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id FuguIC9PIik7; Wed, 6 Mar 2013 12:09:21 -0500 (EST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 6 Mar 2013 12:09:20 -0500 (EST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 8B2B380D39; Wed, 6 Mar 2013 12:09:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7E4E5804F3; Wed, 6 Mar 2013 12:09:21 -0500 (EST) Date: Wed, 6 Mar 2013 12:09:21 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Tero Kivinen In-Reply-To: <20789.55344.544698.606624@fireball.kivinen.iki.fi> Message-ID: References: <0E86FFD429E5FA4A97B86698F6C32AF81C271A91@xmb-rcd-x04.cisco.com> <20788.45136.1741.27834@fireball.kivinen.iki.fi> <0E86FFD429E5FA4A97B86698F6C32AF81C271B6F@xmb-rcd-x04.cisco.com> <20789.55344.544698.606624@fireball.kivinen.iki.fi> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "ipsec@ietf.org" , Yoav Nir , "Anoop V A \(anova\)" Subject: Re: [IPsec] Regarding ISAKMP SA lifetime negotiation. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:09:27 -0000 On Tue, 5 Mar 2013, Tero Kivinen wrote: > As I pointed out earlier, attacker can MODIFY the notification data, > so they can change the life time stored inside the notification data > (there are some difficulties there, but lets not go to them). On the > other hand you would never accept any lifetime that would not be > accordingly to your own policy anyways, so this attack isn't that > effective in this case, as attacker can only change lifetime to > something that you would otherwise accept. So in worst case you are in > the same situation you were without this notification. > >> I understand may be other implementation will avoid this extra >> notify - but is there any violation in sending this extra notify in >> these messages? > > Most likely they will ignore the extra notify, but to be safe it might > be better to add vendor id payloads and only send notify if the other > end is sending known vendor id. There are some quite bad IKEv1 > implementations out there, and I would not even try to guess what they > might do when they get extra notification payloads. I already see some different vendorids for this coming in at times. The openswan/libreswan implementations ignore this vid, however I have been thinking about trying to make use of it on the initiator. It is useful if the responder is set to never rekey. If you don't take their lifetime into account, the IPsec SA can silently die (Cisco does this to me) if their lifetime is shorter. Or the remote could send a Delete/Notify and then the tunnel could be briefly down while the initiator re-initiates. The work around now is to ensure to set the keylife shorter on the initiator so you avoid these issues, but that requires manual and per case configuration. Paul From paul.hoffman@vpnc.org Fri Mar 8 08:17:48 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1F721F886D for ; Fri, 8 Mar 2013 08:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdjTroyqLa8R for ; Fri, 8 Mar 2013 08:17:47 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BB17B21F885E for ; Fri, 8 Mar 2013 08:17:46 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r28GHjVK078330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 8 Mar 2013 09:17:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <381E4CBE-02E3-4F08-9EC3-03C5BCF96501@vpnc.org> Date: Fri, 8 Mar 2013 08:17:46 -0800 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [IPsec] Need slides for the meeting on Tuesday X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 16:17:48 -0000 Greetings again. The agenda is as follows. If you're a presenter and = your presentation is marked as "STILL NEED SLIDES", please get those to = me ASAP. Thanks! --Paul Hoffman Auto Discovery VPN Problem Statement and Requirements - 15 mins http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem STILL NEED SLIDES A TCP transport for the Internet Key Exchange - 20 mins http://tools.ietf.org/html/draft-ietf-ipsecme-ike-tcp STILL NEED SLIDES Additional Diffie-Hellman Tests for IKEv2 - 5 mins http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks HAVE SLIDES Signature Authentication in IKEv2 - 10 mins http://tools.ietf.org/html/draft-kivinen-ipsecme-signature-auth STILL NEED SLIDES More Raw Public Keys for IKEv2 - 5 mins http://tools.ietf.org/html/draft-kivinen-ipsecme-oob-pubkey STILL NEED SLIDES Cryptographic Algorithm Implementation Requirements and Usage Guidance = for ESP and AH - 15 mins Not-quite-submitted draft HAVE SLIDES Gateway discovery and addressing - 5 mins = http://tools.ietf.org/html/draft-mglt-ipsecme-security-gateway-discovery http://tools.ietf.org/html/draft-mglt-ipsecme-alternate-outer-address STILL NEED SLIDES simple VPN solution using Multi-point Security Association - 5 mins http://tools.ietf.org/html/draft-yamaya-ipsecme-mpsa STILL NEED SLIDES If time permits: draft-gundavelli-ipsecme-3gpp-ims-options - 5 mins STILL NEED SLIDES From paul@cypherpunks.ca Fri Mar 8 15:14:26 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AEE21F84EF for ; Fri, 8 Mar 2013 15:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7CodhT6N2hk for ; Fri, 8 Mar 2013 15:14:25 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id B2A4B21F84DC for ; Fri, 8 Mar 2013 15:14:25 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZN4KT50tnz7t1; Fri, 8 Mar 2013 18:14:21 -0500 (EST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id R13Rp_9LSYBz; Fri, 8 Mar 2013 18:14:16 -0500 (EST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP; Fri, 8 Mar 2013 18:14:15 -0500 (EST) Received: by bofh.nohats.ca (Postfix, from userid 500) id A8C2180D39; Fri, 8 Mar 2013 18:14:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A043F80D38; Fri, 8 Mar 2013 18:14:16 -0500 (EST) Date: Fri, 8 Mar 2013 18:14:16 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: svan@elvis.ru Subject: [IPsec] draft-smyslov-ipsecme-ikev2-fragmentation-00 fragmentation size question X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 23:14:26 -0000 I have a question about http://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-fragmentation-00#section-2.5.1 It states: 2.5.1. Fragment size When breaking content of Encrypted Payload down into parts sender SHOULD chose size of those parts so, that resulting message sizes not exceed fragmentation threshold - be small enough to avoid IP fragmentation. If sender has some knowledge about PMTU size it MAY use it. Otherwise for messages to be sent over IPv6 it is RECOMMENDED to use value 1280 bytes as a maximum message size ([RFC2460]). For messages to be sent over IPv4 it is RECOMENDED to use value 576 bytes as a maximum message size. What is "message size" here referring to? The fragmentation payload, or the total packet length? That is, is it recommended that the packet size is 576/1280 including the full IP header and ISAKMP header, or that the packet size is 576/1280 plus the IP header and ISAKMP header? (and can the text in the next draft be clarified to indicate this better?) Paul From david.black@emc.com Sat Mar 9 18:36:51 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F3D21F880B for ; Sat, 9 Mar 2013 18:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2NVbfMj+4gC for ; Sat, 9 Mar 2013 18:36:50 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD1921F8808 for ; Sat, 9 Mar 2013 18:36:49 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2A2an0Q015457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 9 Mar 2013 21:36:49 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Sat, 9 Mar 2013 21:36:36 -0500 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2A2aacb019165 for ; Sat, 9 Mar 2013 21:36:36 -0500 Received: from mx15a.corp.emc.com ([169.254.1.118]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Sat, 9 Mar 2013 21:36:35 -0500 From: "Black, David" To: IPsecme WG Date: Sat, 9 Mar 2013 21:36:33 -0500 Thread-Topic: storm WG: Updating RFC 3723's IP Storage profile of IPsec Thread-Index: Ac4dOBRvvZWctvprSGychCcwUc4Vpg== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71290DCD887@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "Black, David" Subject: [IPsec] storm WG: Updating RFC 3723's IP Storage profile of IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 02:36:51 -0000 In connection with updating iSCSI, the storm WG is going to need to update the IP Storage profile of IPsec in RFC 3723. I'm sending this note to the ipsecme WG now, as I think this is related to the discussion of cryptographic algorithm requirements on Tuesday. **IMPORTANT**: The RFC 3723 profile of IPsec differed from the cryptographi= c algorithm requirements for IPsec v2 (24xx RFCs) on which RFC 3723 was based= , and I expect this to continue to be true for the update to RFC 3723 wrt the new cryptographic algorithm requirements. Chairs - I'd be willing to put up a slide or 2 on this at the meeting if yo= u think that would be useful. -- RFC 3723 Here's what RFC 3723 had to say about cryptographic algorithms: To provide confidentiality with ESP, ESP with 3DES in CBC mode [RFC2451][3DESANSI] MUST be supported, and AES in Counter mode, as described in [RFC3686], SHOULD be supported. To provide data origin authentication and integrity with ESP, HMAC-SHA1 [RFC2404] MUST be supported, and AES in CBC MAC mode with XCBC extensions [RFC3566] SHOULD be supported. DES in CBC mode SHOULD NOT be used due to its inherent weakness. ESP with NULL encryption MUST be supported for authentication. -- Data Integrity and Origin Authentication changes The only proposed change for these algorithm requirements is to add: - Implementations that support IKEv2 [RFC5996] SHOULD also implement AES GMAC [RFC4543]=20 -- Encryption Algorithm changes This one's a bit more involved, because there are concerns with both of the encryption algorithms for which RFC 3723 stated requirements. (1) The MUST for 3DES-CBC has become questionable due to 3DES's 64 bit block size, i.e., the core cipher encrypts or decrypts 64 bits at a time. Things start to go awry cryptographically as one approaches the birthday bound of 32GB (GigaBytes) of data encrypted under the same key. As a reminder, here are a couple of links: http://www.ietf.org/mail-archive/web/ipsec/current/msg07997.html http://www.ietf.org/mail-archive/web/ipsec/current/msg08031.html How far away to stay from that bound is a judgment call, but 32GB or some fraction thereof is not a lot of data for iSCSI to move. One could deal with this via rekeying, but the result will be rather frequent rekeying if one decides to stay at least an order of magnitude away on a multi-gigabit/sec link. In contrast, AES has a 128 bit blocksize, and so its birthday bound is astronomical (2^69 bytes if I have the math right). AES CBC is the most common mandatory-to-implement mode for interoperability. (2) AES CTR was originally selected for its hardware friendliness (e.g., it pipelines well), even though there was no hardware friendly integrity MAC algorithm to go with it at the time. AES GCM is now the strongly preferred choice, as it provides encryption and a MAC. ... Now comes the fun ... Proposal (w/o RFC citations, all AES requirements are for 128 bit keys): - 3DES in CBC mode MAY be implemented (previously MUST) - AES in CBC mode MUST be implemented (previously implicitly MAY) - AES in Counter mode MAY be implemented (previously SHOULD) - Implementations that support IKEv2 SHOULD also implement AES GCM (new requirement) - DES MUST NOT be implemented or used (previously SHOULD NOT) - NULL encryption MUST be implemented (no change) The intent is that these requirements are readily met by widely available IPsec implementations. Thanks, --David (storm WG co-chair) ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From paul@cypherpunks.ca Mon Mar 11 08:12:45 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91AE11E8104 for ; Mon, 11 Mar 2013 08:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgdSTZLy+AAQ for ; Mon, 11 Mar 2013 08:12:45 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3524D11E8117 for ; Mon, 11 Mar 2013 08:12:45 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZPjVL75NQz9cg; Mon, 11 Mar 2013 11:12:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id GsKBfhkgLGQE; Mon, 11 Mar 2013 11:12:40 -0400 (EDT) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 11 Mar 2013 11:12:40 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id A585F80D39; Mon, 11 Mar 2013 11:12:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9A78580D38; Mon, 11 Mar 2013 11:12:40 -0400 (EDT) Date: Mon, 11 Mar 2013 11:12:40 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Valery Smyslov In-Reply-To: <62ABEDA45A2B4E2CBA7425644643F960@buildpc> Message-ID: References: <62ABEDA45A2B4E2CBA7425644643F960@buildpc> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] draft-smyslov-ipsecme-ikev2-fragmentation-00 fragmentation size question X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 15:12:45 -0000 On Mon, 11 Mar 2013, Valery Smyslov wrote: >> I have a question about >> >> http://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-fragmentation-00#section-2.5.1 >> >> It states: >> >> 2.5.1. Fragment size >> What is "message size" here referring to? The fragmentation payload, or >> the total packet length? >> >> That is, is it recommended that the packet size is 576/1280 including >> the full IP header and ISAKMP header, or that the packet size is >> 576/1280 plus the IP header and ISAKMP header? > > The total IP packet length (including IP header, UDP header, IKE header). > >> (and can the text in the next draft be clarified to indicate this >> better?) > > Sorry for being not very precise. I'll try to clarify it in the next version. It might be more useful to implementors to know the IKE message size upon which they should fragment, as opopsed to having to calculate the values of IP headers, UDP headers and IKE header with fragmentation payload themselves? So can the draft specify those (and or both) ? Paul From svan@elvis.ru Sun Mar 10 22:36:18 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4F821F88C8 for ; Sun, 10 Mar 2013 22:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.285 X-Spam-Level: * X-Spam-Status: No, score=1.285 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75rZgJJ1UjkW for ; Sun, 10 Mar 2013 22:36:17 -0700 (PDT) Received: from bull.elvis.ru (bull.elvis.ru [93.188.44.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3FC21F8837 for ; Sun, 10 Mar 2013 22:36:16 -0700 (PDT) Received: from robin.office.elvis.ru ([10.111.1.40]) by bull.elvis.ru with esmtp (Exim 4.76) (envelope-from ) id 1UEvP9-0006bL-A1; Mon, 11 Mar 2013 09:36:11 +0400 Received: from buildpc (10.111.10.31) by robin.office.elvis.ru (10.111.1.40) with Microsoft SMTP Server id 14.1.438.0; Mon, 11 Mar 2013 09:35:27 +0400 Message-ID: <62ABEDA45A2B4E2CBA7425644643F960@buildpc> From: Valery Smyslov To: Paul Wouters References: Date: Mon, 11 Mar 2013 09:36:10 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Mailman-Approved-At: Mon, 11 Mar 2013 08:20:44 -0700 Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-smyslov-ipsecme-ikev2-fragmentation-00 fragmentation size question X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 05:50:26 -0000 Hi, Paul, thank you for reading the draft. > I have a question about > > http://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-fragmentation-00#section-2.5.1 > > It states: > > 2.5.1. Fragment size > > > When breaking content of Encrypted Payload down into parts sender > SHOULD chose size of those parts so, that resulting message sizes not > exceed fragmentation threshold - be small enough to avoid IP > fragmentation. > > If sender has some knowledge about PMTU size it MAY use it. > Otherwise for messages to be sent over IPv6 it is RECOMMENDED to use > value 1280 bytes as a maximum message size ([RFC2460]). For messages > to be sent over IPv4 it is RECOMENDED to use value 576 bytes as a > maximum message size. > > > What is "message size" here referring to? The fragmentation payload, or > the total packet length? > > That is, is it recommended that the packet size is 576/1280 including > the full IP header and ISAKMP header, or that the packet size is > 576/1280 plus the IP header and ISAKMP header? The total IP packet length (including IP header, UDP header, IKE header). > (and can the text in the next draft be clarified to indicate this > better?) Sorry for being not very precise. I'll try to clarify it in the next version. > Paul Regards, Valery. From pwouters@redhat.com Mon Mar 11 10:25:29 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982B211E80F7 for ; Mon, 11 Mar 2013 10:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VQf7BuVZYlY for ; Mon, 11 Mar 2013 10:25:29 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id A62D711E80CC for ; Mon, 11 Mar 2013 10:25:28 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZPmRP5vp9z9h6; Mon, 11 Mar 2013 13:25:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id vFn0lXDsFK1q; Mon, 11 Mar 2013 13:25:13 -0400 (EDT) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 11 Mar 2013 13:25:11 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 09BE080D39; Mon, 11 Mar 2013 13:25:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F3E4480D38; Mon, 11 Mar 2013 13:25:05 -0400 (EDT) Date: Mon, 11 Mar 2013 13:25:05 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: IPsecme WG Message-ID: User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: draft-yamaya-ipsecme-mpsa@tools.ietf.org Subject: Re: [IPsec] draft-yamaya-ipsecme-mpsa-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 17:25:29 -0000 Regarding draft-yamaya-ipsecme-mpsa-00 The draft claims to be about "auto discovery and configuration function". However, I don't actually see any of that in the draft. I have no idea how nodes find out about other nodes they can talk IPsec to. What I do see in the draft is a mechanism for a gateway to relay keying material (nonces!!) for a shared IPsec SA to other nodes after authenticating such nodes. That raises a few questions for me: If we want to accomplish a gateway allowing authenticated parties into a collection of IPsec nodes, why not negotiate separate SA's? There is no real reason to use a single shared IPsec SA session key, and it vastly reduced the security. One conpromised node would reveal the IPsec SA keying material, and with that an attacker could decrypt all the traffic between all the nodes. Plus an attacker could just add a new node to the system (depending on the discovery/permission model that I don't fully understand) Why not distribute some kind of token or PSK between gateway and endpoints, so that two endpoints can then use that to setup the parent SA and do a proper setup of any child SAs with a unique keying material for those nodes? As a bonus, that will keep to a much closer deployment to the existing method. A compromised node might be able to attach itself to the group, but it won't allow the direct compromise of any other node-to-node traffic in the collection. Also this allows each node to reject any proposals for IP address ranges it is unwilling to relay to a particular node. Furthermore, I see no discovery method in the draft that tells a node which other nodes are available via this shared MPSA. How does a node know it can do the MPSA to another node? It seems the draft has no method for asking the gateway about this. Without such a discovery, administrators will still end up having to hardcode node configuration, which is exactly what we are trying to avoid. While the diagrams display there can be gateway-endnode and endnode-endnode traffic using the MPSA, I see no way how the endnode could know this. As a node, I have traffic destined for 192.0.2.1. Should I use an MPSA? I see no correlation between SRC / DST IP addresses and the MPSA. Does this mean any endnode can connect to any other endnode within the group and just make up its own ranges? like 0.0.0.0/0 <-> 0.0.0.0/0 ? That seems like a very weak trust model. Additionally, what if I want my node to be in more then one MPSA group ? Can I have two MPSA's ? How would I know a node is connecting to me is for "MPSA 1" versus "MPSA 2" ? Is there any IKE association between nodes? Or will they just start sending me encrypted ESP for the MPSA? What if someone replays some MPSA encrypted traffic appearing from one node, will my node suddenly stop talking cleartext to it? That seems a weak authentication model. I find the terminology for "rollover time1" (ROLL1) and "rollover time2" (ROLL2) confusing, as it seems to actually be more representative of an "expiration date" and an "activation date". It seems to also overlap with "lifetime" (LIFE). Doubly so as the expiration for ROLL1 has to be related to the start of ROLL2. So we know when to roll, but we still need to connect to the gateway to get the keying material? So why not just limit everything to an expiration time for when the nodes have to contact the gateway again for the new MPSA keying material? The gateway is supopsed to rekey, but that can be difficult with clients behind NAT. Since the gateway informed the clients about the lifetimes, why not let the clients reconnect? So in short: - Distribute authentication information/permission, not encryption material (IKE SA's and traffic selectors are needed) - Devise a mechanism to obtain a list of active nodes or a method to ask the gateway if a certain node is avaialble via MPSA or not. - Reduce the information sent to the minimum required. - Agree on some kind of scope of IP addresses for the MPSA As it stands, I don't really see myself implementing this. There are too many unanswered security concerns, and it does not have enough discovery features in it for my needs. Paul From praveenys@juniper.net Mon Mar 11 11:26:08 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E6521F8D07 for ; Mon, 11 Mar 2013 11:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVd68jE3761V for ; Mon, 11 Mar 2013 11:26:08 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 46FFE21F8D2D for ; Mon, 11 Mar 2013 11:26:07 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUT4hvtGMC24dg1ffkWyCHSDJzvHQXoVy@postini.com; Mon, 11 Mar 2013 11:26:07 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 11 Mar 2013 11:24:42 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 11 Mar 2013 11:24:41 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.189) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 11 Mar 2013 11:34:03 -0700 Received: from mail56-co1-R.bigfish.com (10.243.78.245) by CO1EHSOBE018.bigfish.com (10.243.66.81) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Mar 2013 18:24:41 +0000 Received: from mail56-co1 (localhost [127.0.0.1]) by mail56-co1-R.bigfish.com (Postfix) with ESMTP id CD08BB00176 for ; Mon, 11 Mar 2013 18:24:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -24 X-BigFish: PS-24(zzbb2dI98dI9371I4015Idb82hzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dh8275bhz2dh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h) Received: from mail56-co1 (localhost.localdomain [127.0.0.1]) by mail56-co1 (MessageSwitch) id 1363026278887158_8718; Mon, 11 Mar 2013 18:24:38 +0000 (UTC) Received: from CO1EHSMHS009.bigfish.com (unknown [10.243.78.248]) by mail56-co1.bigfish.com (Postfix) with ESMTP id D520C3C0084; Mon, 11 Mar 2013 18:24:38 +0000 (UTC) Received: from BLUPRD0511HT003.namprd05.prod.outlook.com (157.56.232.213) by CO1EHSMHS009.bigfish.com (10.243.66.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 11 Mar 2013 18:24:37 +0000 Received: from BLUPRD0511MB413.namprd05.prod.outlook.com ([169.254.6.62]) by BLUPRD0511HT003.namprd05.prod.outlook.com ([10.255.135.166]) with mapi id 14.16.0275.006; Mon, 11 Mar 2013 18:24:29 +0000 From: Praveen Sathyanarayan To: Paul Wouters , IPsecme WG Thread-Topic: [IPsec] draft-yamaya-ipsecme-mpsa-00 Thread-Index: AQHOHn12MjA093XUVE+V2LTszVL35ZigacGA Date: Mon, 11 Mar 2013 18:24:29 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.255.135.132] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%REDHAT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "draft-yamaya-ipsecme-mpsa@tools.ietf.org" Subject: Re: [IPsec] draft-yamaya-ipsecme-mpsa-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:26:09 -0000 If I understood accurately, author meant to establish mesh BGP sessions, which would allow discovery of each other information. But IMO, this may cause scale issue. AD-VPN is mainly to address a large VPN deployments. As an example, say 2000 end-points are deployed. With this MESH approach, there are (2000 - 1) BGP sessions established in each and every end-point. Generally, end-point gateways are small devices, which may not capable of establishing so many BGP sessions. IMO, this is not scalable approach. Also, even though it may not pass traffic to given end-point, it may have to establish BGP sessions with them. I do agree with Paul's other security concerns as well. If hacker can establish a tunnel with gateway and get MP-SA, then all end-points are compromised. I also agree, this draft should add more details. Thanks, Praveen=20 On 3/11/13 10:25 AM, "Paul Wouters" wrote: Regarding draft-yamaya-ipsecme-mpsa-00 The draft claims to be about "auto discovery and configuration function". However, I don't actually see any of that in the draft. I have no idea how nodes find out about other nodes they can talk IPsec to. What I do see in the draft is a mechanism for a gateway to relay keying material (nonces!!) for a shared IPsec SA to other nodes after authenticating such nodes. That raises a few questions for me: If we want to accomplish a gateway allowing authenticated parties into a collection of IPsec nodes, why not negotiate separate SA's? There is no real reason to use a single shared IPsec SA session key, and it vastly reduced the security. One conpromised node would reveal the IPsec SA keying material, and with that an attacker could decrypt all the traffic between all the nodes. Plus an attacker could just add a new node to the system (depending on the discovery/permission model that I don't fully understand) Why not distribute some kind of token or PSK between gateway and endpoints, so that two endpoints can then use that to setup the parent SA and do a proper setup of any child SAs with a unique keying material for those nodes? As a bonus, that will keep to a much closer deployment to the existing method. A compromised node might be able to attach itself to the group, but it won't allow the direct compromise of any other node-to-node traffic in the collection. Also this allows each node to reject any proposals for IP address ranges it is unwilling to relay to a particular node. Furthermore, I see no discovery method in the draft that tells a node which other nodes are available via this shared MPSA. How does a node know it can do the MPSA to another node? It seems the draft has no method for asking the gateway about this. Without such a discovery, administrators will still end up having to hardcode node configuration, which is exactly what we are trying to avoid. While the diagrams display there can be gateway-endnode and endnode-endnode traffic using the MPSA, I see no way how the endnode could know this. As a node, I have traffic destined for 192.0.2.1. Should I use an MPSA? I see no correlation between SRC / DST IP addresses and the MPSA. Does this mean any endnode can connect to any other endnode within the group and just make up its own ranges? like 0.0.0.0/0 <-> 0.0.0.0/0 ? That seems like a very weak trust model. Additionally, what if I want my node to be in more then one MPSA group ? Can I have two MPSA's ? How would I know a node is connecting to me is for "MPSA 1" versus "MPSA 2" ? Is there any IKE association between nodes? Or will they just start sending me encrypted ESP for the MPSA? What if someone replays some MPSA encrypted traffic appearing from one node, will my node suddenly stop talking cleartext to it? That seems a weak authentication model. I find the terminology for "rollover time1" (ROLL1) and "rollover time2" (ROLL2) confusing, as it seems to actually be more representative of an "expiration date" and an "activation date". It seems to also overlap with "lifetime" (LIFE). Doubly so as the expiration for ROLL1 has to be related to the start of ROLL2. So we know when to roll, but we still need to connect to the gateway to get the keying material? So why not just limit everything to an expiration time for when the nodes have to contact the gateway again for the new MPSA keying material? The gateway is supopsed to rekey, but that can be difficult with clients behind NAT. Since the gateway informed the clients about the lifetimes, why not let the clients reconnect? So in short: - Distribute authentication information/permission, not encryption material (IKE SA's and traffic selectors are needed) - Devise a mechanism to obtain a list of active nodes or a method to ask the gateway if a certain node is avaialble via MPSA or not. - Reduce the information sent to the minimum required. - Agree on some kind of scope of IP addresses for the MPSA As it stands, I don't really see myself implementing this. There are too many unanswered security concerns, and it does not have enough discovery features in it for my needs. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ietf@meetecho.com Mon Mar 11 16:18:22 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B9811E8127 for ; Mon, 11 Mar 2013 16:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.644 X-Spam-Level: X-Spam-Status: No, score=-0.644 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEKtIMzUa-yI for ; Mon, 11 Mar 2013 16:18:21 -0700 (PDT) Received: from smtpdg10.aruba.it (smtpdg94.aruba.it [62.149.158.94]) by ietfa.amsl.com (Postfix) with ESMTP id 3732E11E8112 for ; Mon, 11 Mar 2013 16:18:20 -0700 (PDT) Received: from dell-tcastaldi ([130.129.16.136]) by smtpcmd05.ad.aruba.it with bizsmtp id APJG1l00K2w8SR601PJJxU; Tue, 12 Mar 2013 00:18:19 +0100 Date: Mon, 11 Mar 2013 19:18:15 -0400 (EDT) From: Meetecho Team To: ipsec@ietf.org Message-ID: <860069.1.1363043895371.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_2614099.1363043895283" Subject: [IPsec] Meetecho support for IPSECME session X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 23:18:22 -0000 ------=_Part_0_2614099.1363043895283 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, a virtual room has been reserved on the Meetecho system for the IPSEC WG meeting session. Access to the on-line session (including audio and video streams) will be made available (just a couple of minutes before session start time) at: http://www.meetecho.com/ietf86/ipsecme The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf86 Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_0_2614099.1363043895283-- From internet-drafts@ietf.org Tue Mar 12 00:20:07 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6A521F8758; Tue, 12 Mar 2013 00:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxhgD76nGHDf; Tue, 12 Mar 2013 00:20:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5895221F853D; Tue, 12 Mar 2013 00:20:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.42 Message-ID: <20130312072005.15607.45754.idtracker@ietfa.amsl.com> Date: Tue, 12 Mar 2013 00:20:05 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 07:20:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : Cryptographic Algorithm Implementation Requirements and = Usage Guidance for Encapsulating Security Payload (ESP) and Authentication = Header (AH) Author(s) : David McGrew Wajdi Feghali Filename : draft-ietf-ipsecme-esp-ah-reqts-00.txt Pages : 17 Date : 2013-03-11 Abstract: This Internet Draft is standards track proposal to update to the Cryptographic Algorithm Implementation Requirements for ESP and AH; it also adds usage guidance to help in the selection of these algorithms. The Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols makes use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sheila.frankel@nist.gov Tue Mar 12 07:03:26 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87CB221F8AF0 for ; Tue, 12 Mar 2013 07:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GfHQcdbGQbi for ; Tue, 12 Mar 2013 07:03:26 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id D6F5A21F8AE3 for ; Tue, 12 Mar 2013 07:03:25 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 12 Mar 2013 10:02:48 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 12 Mar 2013 10:03:25 -0400 From: "Frankel, Sheila E." To: IPsecme WG Date: Tue, 12 Mar 2013 10:01:52 -0400 Thread-Topic: Updated ESP/AH algorithm I-D Thread-Index: AQHOHypcZWhf/6yZR0un+EanXx7lZA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: [IPsec] Updated ESP/AH algorithm I-D X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:03:26 -0000 Hi David and Wajdi, Your updated ESP/AH algorithm doc looks great, and is very much needed. I just have one comment. You speak of the 2 services provided by ESP and AH as confidentiality and "data origin authentication." As I'm sure you know, authentication is used in different ways by different communities. I believe that in most of the IPsec docs the 1st service is referred to interchangeably as encryption and confidentiality; the 2nd service is interchangeably referred to as authentication and integrity protection. However, in RFC 4303 (ESP) it states: "Data origin authentication and connectionless integrity are joint services, hereafter referred to jointly as "integrity"." In your doc, the integrity-protection aspect is not mentioned at all, and I believe that is a critical oversight. Sheila Frankel From pwouters@redhat.com Tue Mar 12 07:41:26 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13AD21F8C08 for ; Tue, 12 Mar 2013 07:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wipNaslwBx-p for ; Tue, 12 Mar 2013 07:41:24 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id B7A1B21F8C04 for ; Tue, 12 Mar 2013 07:41:24 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZQJlZ40Jjz5LC for ; Tue, 12 Mar 2013 10:41:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id dclTktUvCh-E for ; Tue, 12 Mar 2013 10:41:09 -0400 (EDT) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP for ; Tue, 12 Mar 2013 10:41:09 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 1570A80860; Tue, 12 Mar 2013 10:41:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 092FA8043D for ; Tue, 12 Mar 2013 10:41:08 -0400 (EDT) Date: Tue, 12 Mar 2013 10:41:08 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [IPsec] note on ike fragmentation and ike over tcp X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:41:27 -0000 (missed from the jabber room) The bug mentioned that there was a lot of IKE fragments for IKEv1 without seeing the FRAGMENTATION vendorid was solved. It was iOS 6.0 and they fixed it since. (either in 6.01 or 6.1) It did cause people to be forced to implement fragmentation for IKEv1. The best "specification" I found was at Microsoft: http://msdn.microsoft.com/en-us/library/cc233452.aspx However note that it seems most (every?) implementation only uses fragment ID = 1. Probably because that field is useless and an IETF review would have found that and kicked it out :) There seem to be different tresholds for when to do fragmentation. Stock racoon uses 552, while racoon on iOS uses 1280. We (libreswan) ran into strange Linux kernel issues for IPv6 when using 552 (might be our own fault). Neither upstream racoon or iOS racoon treats IPv4 different from IPv6. Libreswan uses 552 for IPv4 and 1240 for IPv6 but that might change, as our exposure and interop experience is rather new (and mostly with racoon or racoon-derivatives code such as strongswan) Note also that it is likely there could be interoperability issues because the racoon code (and the strongswan port of that) are directly using sizeof(struct) for wire format, so we might see strange issues on certain CPUs now or in the future due to alignments. The fragmentation seems pretty straightforward. I personally like not needing to rely on TCP (which can be trivially DOS'ed using an unauthenticated TCP RST packet). So I'm with Tero that if IKE fragmentation works, and it seems that it does, the incentive for implementing IKE over TCP is low, while the changes are pretty invasive. So I am okay with abandoning it for now. Paul From yaronf.ietf@gmail.com Tue Mar 12 07:48:51 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7241021F8C78 for ; Tue, 12 Mar 2013 07:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.829 X-Spam-Level: X-Spam-Status: No, score=-100.829 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuh+73SbEFfM for ; Tue, 12 Mar 2013 07:48:51 -0700 (PDT) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id A317821F8C7C for ; Tue, 12 Mar 2013 07:48:50 -0700 (PDT) Received: by mail-bk0-f52.google.com with SMTP id jk13so2266373bkc.39 for ; Tue, 12 Mar 2013 07:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=uYf2NryzJ0xJqw0L05FJ+Lf2mVxIFFcHJfpbkONkVFk=; b=k0tHzxuYTDGgxfueLgtAJVb7v38AR+BpT3WvqK+4yPbHj/w2fC74eIvrQiLECJHD46 ME4YiIP5ngyoTM+5+YyGfKsDeKOw1oPl846+Thrego6yuJccurgL7XMLjYKhWYkH0nc9 wnF/GiLzM4CqBLmK7OEcG3iv3FkM56hieQRu+R4uyQsIGGd1D7wCPqt8t+WU5IPzXjDd h9bak/k5neKRgzk835DffKttlg92fmRyk/uKpCbPkA/c4JRXgKBHxH6muLRyzJtd7oGr T7XWeHl2pA+6bQvCQeiFrCiCWNM0F96m7pIWMtH4M6pvN1+oZM4mQUk7E6KLGf+sJ+dr Z3WA== X-Received: by 10.205.13.193 with SMTP id pn1mr6216694bkb.114.1363099729533; Tue, 12 Mar 2013 07:48:49 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-176-129-128.red.bezeqint.net. [79.176.129.128]) by mx.google.com with ESMTPS id go8sm5165479bkc.20.2013.03.12.07.48.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 07:48:48 -0700 (PDT) Message-ID: <513F404E.5060608@gmail.com> Date: Tue, 12 Mar 2013 16:48:46 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] DH Tests draft - failure behavior X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:48:51 -0000 Following up on the discussion we just had: Paul raised the question whether we should respond with an error message in case any of the tests fail. We know from many examples that errors can reveal secret information. However in this particular case: - All IKEv2 DH groups are public information. - All of the proposed tests only depend on public information, plus the information received from the sender in the clear. In other words, the test could just as well be performed by an eavesdropper. The only thing that such an error message does reveal is that the receiver implements the test, but this is something that an attacker can find out anyway. Which is why I think we should treat such failures as a normal syntax error, and respond with an error message, as a courtesy to the sender. We should make these considerations explicit in the draft, specifically that the groups are well known. Thanks, Yaron From kent@bbn.com Tue Mar 12 08:09:14 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5796921F83E1 for ; Tue, 12 Mar 2013 08:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVE5o5zHxzDM for ; Tue, 12 Mar 2013 08:09:13 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE5B21F89FB for ; Tue, 12 Mar 2013 08:09:13 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:36011 helo=dhcp-1067.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UFQpD-0005Cc-HD; Tue, 12 Mar 2013 11:09:11 -0400 Message-ID: <513F4516.8080905@bbn.com> Date: Tue, 12 Mar 2013 11:09:10 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: ipsec@ietf.org, sheila.frankel@nist.gov References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Updated ESP/AH algorithm I-D X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 15:09:14 -0000 Sheila, I did a quick check of 4301, and it uses the term "confidentiality" consistently when referring to the service, and uses "encryption" to refer to the mechanism. They are not used interchangeably. The same seems to apply to use of terminology re data origin authentication, integrity, etc. Steve On 3/12/13 10:01 AM, Frankel, Sheila E. wrote: > Hi David and Wajdi, > > Your updated ESP/AH algorithm doc looks great, and is very much needed. I just have one comment. You speak of the 2 services provided by ESP and AH as confidentiality and "data origin authentication." As I'm sure you know, authentication is used in different ways by different communities. I believe that in most of the IPsec docs the 1st service is referred to interchangeably as encryption and confidentiality; the 2nd service is interchangeably referred to as authentication and integrity protection. However, in RFC 4303 (ESP) it states: "Data origin authentication and connectionless integrity are joint services, hereafter referred to jointly as "integrity"." In your doc, the integrity-protection aspect is not mentioned at all, and I believe that is a critical oversight. > > Sheila Frankel > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From sheila.frankel@nist.gov Tue Mar 12 09:57:47 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D3311E80D1 for ; Tue, 12 Mar 2013 09:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BSO0oDZ7SO5 for ; Tue, 12 Mar 2013 09:57:44 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 2969E11E80D9 for ; Tue, 12 Mar 2013 09:57:42 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 12 Mar 2013 12:58:03 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 12 Mar 2013 12:57:39 -0400 From: "Frankel, Sheila E." To: Stephen Kent , "ipsec@ietf.org" Date: Tue, 12 Mar 2013 12:56:04 -0400 Thread-Topic: [IPsec] Updated ESP/AH algorithm I-D Thread-Index: Ac4fM49f6VjiGP1nRiatud2VRkGpowADuwr6 Message-ID: References: , <513F4516.8080905@bbn.com> In-Reply-To: <513F4516.8080905@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [IPsec] Updated ESP/AH algorithm I-D X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 16:57:47 -0000 X-List-Received-Date: Tue, 12 Mar 2013 16:57:47 -0000 Steve, Perhaps I wasn't clear in the main thrust of my message. I'm not quibbling about terminology; I'm concerned that the I-D is lacking some vital information. The I-D discusses 2 services provided by ESP and AH: confidentiality and data origin authentication. My point was that the 2nd service includes connectionless integrity protection as well - which is not identical to data origin authentication - and therefore integrity protection should be mentioned in the I-D. Sheila ________________________________________ From: Stephen Kent [kent@bbn.com] Sent: Tuesday, March 12, 2013 11:09 AM To: ipsec@ietf.org; Frankel, Sheila E. Subject: Re: [IPsec] Updated ESP/AH algorithm I-D Sheila, I did a quick check of 4301, and it uses the term "confidentiality" consistently when referring to the service, and uses "encryption" to refer to the mechanism. They are not used interchangeably. The same seems to apply to use of terminology re data origin authentication, integrity, etc. Steve On 3/12/13 10:01 AM, Frankel, Sheila E. wrote: > Hi David and Wajdi, > > Your updated ESP/AH algorithm doc looks great, and is very much needed. I just have one comment. You speak of the 2 services provided by ESP and AH as confidentiality and "data origin authentication." As I'm sure you know, authentication is used in different ways by different communities. I believe that in most of the IPsec docs the 1st service is referred to interchangeably as encryption and confidentiality; the 2nd service is interchangeably referred to as authentication and integrity protection. However, in RFC 4303 (ESP) it states: "Data origin authentication and connectionless integrity are joint services, hereafter referred to jointly as "integrity"." In your doc, the integrity-protection aspect is not mentioned at all, and I believe that is a critical oversight. > > Sheila Frankel From kent@bbn.com Tue Mar 12 10:05:03 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C95A21F8A6B for ; Tue, 12 Mar 2013 10:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIDc78XqKD-U for ; Tue, 12 Mar 2013 10:05:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A3D3721F8A48 for ; Tue, 12 Mar 2013 10:05:02 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:45766 helo=dhcp-1067.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UFSdJ-000DnA-8s; Tue, 12 Mar 2013 13:05:01 -0400 Message-ID: <513F603C.1030007@bbn.com> Date: Tue, 12 Mar 2013 13:05:00 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: ipsec@ietf.org, sheila.frankel@nist.gov References: , <513F4516.8080905@bbn.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Updated ESP/AH algorithm I-D X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 17:05:03 -0000 Sheila, I understood your point. I objected to your statement that other IPsec RFC were sloppy in the use of security service/mechanism terminology. Steve > Steve, > > Perhaps I wasn't clear in the main thrust of my message. I'm not quibbling about terminology; I'm concerned that the I-D is lacking some vital information. The I-D discusses 2 services provided by ESP and AH: confidentiality and data origin authentication. My point was that the 2nd service includes connectionless integrity protection as well - which is not identical to data origin authentication - and therefore integrity protection should be mentioned in the I-D. > > Sheila > From kivinen@iki.fi Tue Mar 12 10:45:57 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9829321F89EE for ; Tue, 12 Mar 2013 10:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SizQrPAcGg54 for ; Tue, 12 Mar 2013 10:45:54 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A6D21F89B5 for ; Tue, 12 Mar 2013 10:45:53 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r2CHiSJq022444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Mar 2013 19:44:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r2CHiRfx023705; Tue, 12 Mar 2013 19:44:27 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20799.27003.633105.446538@fireball.kivinen.iki.fi> Date: Tue, 12 Mar 2013 19:44:27 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <513F404E.5060608@gmail.com> References: <513F404E.5060608@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: IPsecme WG Subject: [IPsec] DH Tests draft - failure behavior X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 17:45:57 -0000 Yaron Sheffer writes: > Following up on the discussion we just had: > > Paul raised the question whether we should respond with an error message > in case any of the tests fail. We know from many examples that errors > can reveal secret information. > > However in this particular case: > > - All IKEv2 DH groups are public information. > - All of the proposed tests only depend on public information, plus the > information received from the sender in the clear. In other words, the > test could just as well be performed by an eavesdropper. > > The only thing that such an error message does reveal is that the > receiver implements the test, but this is something that an attacker can > find out anyway. > > Which is why I think we should treat such failures as a normal syntax > error, and respond with an error message, as a courtesy to the sender. > > We should make these considerations explicit in the draft, specifically > that the groups are well known. On the other hand failure there means we didn't manage to negotiate shared secret, thus the whatever error message we sent out must be unauthenticated. The recipient of such unauthenticated notify cannot act directly on it, as attacker might have sent it instead of the real peer, and real peer might actually take some time to do the checks and other calculations before answering. Befcause of this sending the notification does not help that much, it only opens new way to do DoS attack. As this error cannot happen in valid implementations, it is always either attack or implementation working incorrectly, I see no point of making special code for error messages in that case. My recommendation is that the recipient will simply silently ignore the IKE_SA_INIT packet having invalid KE payload. It MAY continue keep setting up the SA, i.e. see if there is properly formatted and generated KE payload in the future. Otherwise the attacker could again do DoS attack against the peer, by sending there IKE_SA_INIT response with invalid KE payload and cause inititor to drop the connection before the real responder have time to reply. -- kivinen@iki.fi From ietf@meetecho.com Tue Mar 12 11:01:04 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91AE621F85AC for ; Tue, 12 Mar 2013 11:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWf-nrH-8vye for ; Tue, 12 Mar 2013 11:00:59 -0700 (PDT) Received: from smtpdg2.aruba.it (smtpdg220.aruba.it [62.149.158.220]) by ietfa.amsl.com (Postfix) with ESMTP id 218EE21F8AB2 for ; Tue, 12 Mar 2013 10:59:26 -0700 (PDT) Received: from dell-tcastaldi ([130.129.16.136]) by smtpcmd01.ad.aruba.it with bizsmtp id AhzC1l00M2w8SR601hzEqr; Tue, 12 Mar 2013 18:59:15 +0100 Date: Tue, 12 Mar 2013 13:59:11 -0400 (EDT) From: Meetecho Team To: ipsec@ietf.org Message-ID: <13238549.1.1363111151390.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_2614099.1363111151341" Subject: [IPsec] IPSECME session recording available X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 18:01:04 -0000 ------=_Part_0_2614099.1363111151341 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the IPSECME WG session at IETF 86 is available at the following URL: http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_0_2614099.1363111151341-- From sheila.frankel@nist.gov Tue Mar 12 11:15:47 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F326221F8AAD for ; Tue, 12 Mar 2013 11:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzZ1hHr1wuJM for ; Tue, 12 Mar 2013 11:15:46 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 9063821F86DD for ; Tue, 12 Mar 2013 11:15:45 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 12 Mar 2013 14:16:08 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 12 Mar 2013 14:15:44 -0400 From: "Frankel, Sheila E." To: Stephen Kent , "ipsec@ietf.org" Date: Tue, 12 Mar 2013 14:14:54 -0400 Thread-Topic: [IPsec] Updated ESP/AH algorithm I-D Thread-Index: Ac4fQ7/HW0cA+yBGQfGrxh+saHayBQACb8o7 Message-ID: References: , <513F4516.8080905@bbn.com> , <513F603C.1030007@bbn.com> In-Reply-To: <513F603C.1030007@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [IPsec] Updated ESP/AH algorithm I-D X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 18:15:47 -0000 Steve, I certainly didn't intend any insults, and I wouldn't characterize the wording in the RFC's as sloppy. It's very common to use these terms somewhat interchangeably. Sorry if my wording could be construed as a criticism. That's the last thing I'd want, considering the tremendous amount of hard work that went into the RFCs. Regards, Sheila ________________________________________ From: Stephen Kent [kent@bbn.com] Sent: Tuesday, March 12, 2013 1:05 PM To: ipsec@ietf.org; Frankel, Sheila E. Subject: Re: [IPsec] Updated ESP/AH algorithm I-D Sheila, I understood your point. I objected to your statement that other IPsec RFC were sloppy in the use of security service/mechanism terminology. Steve > Steve, > > Perhaps I wasn't clear in the main thrust of my message. I'm not quibbling about terminology; I'm concerned that the I-D is lacking some vital information. The I-D discusses 2 services provided by ESP and AH: confidentiality and data origin authentication. My point was that the 2nd service includes connectionless integrity protection as well - which is not identical to data origin authentication - and therefore integrity protection should be mentioned in the I-D. > > Sheila > From paul.hoffman@vpnc.org Tue Mar 12 11:28:34 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700F111E815C for ; Tue, 12 Mar 2013 11:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xG4sbfhj4+qi for ; Tue, 12 Mar 2013 11:28:33 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 87F1A11E8156 for ; Tue, 12 Mar 2013 11:28:33 -0700 (PDT) Received: from dhcp-6061.meeting.ietf.org (dhcp-6061.meeting.ietf.org [130.129.96.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r2CISNx0094673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 12 Mar 2013 11:28:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0A7279E5-312A-4535-89C4-C1AF06C02DC3@vpnc.org> Date: Tue, 12 Mar 2013 14:28:22 -0400 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [IPsec] Preliminary minutes from today's meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 18:28:34 -0000 ...are at http://www.ietf.org/proceedings/86/minutes/minutes-86-ipsecme Please send changes *to the minutes* to the list. If you want to discuss = something that was discussed in the minutes, please start a new mail = thread. Thanks! (And thanks to Dan Harkins for turning these around = quickly.) --Paul Hoffman= From kivinen@iki.fi Tue Mar 12 12:44:25 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160FC11E8129 for ; Tue, 12 Mar 2013 12:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vg1eC+VRvWtO for ; Tue, 12 Mar 2013 12:44:24 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F51F11E8142 for ; Tue, 12 Mar 2013 12:44:22 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r2CJh1wV024620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Mar 2013 21:43:01 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r2CJh1lO008701; Tue, 12 Mar 2013 21:43:01 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20799.34117.86998.862225@fireball.kivinen.iki.fi> Date: Tue, 12 Mar 2013 21:43:01 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: <0A7279E5-312A-4535-89C4-C1AF06C02DC3@vpnc.org> References: <0A7279E5-312A-4535-89C4-C1AF06C02DC3@vpnc.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 6 min Cc: IPsecme WG Subject: [IPsec] Preliminary minutes from today's meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 19:44:25 -0000 Paul Hoffman writes: > ...are at http://www.ietf.org/proceedings/86/minutes/minutes-86-ipsecme > > Please send changes *to the minutes* to the list. If you want to > discuss something that was discussed in the minutes, please start a > new mail thread. Thanks! (And thanks to Dan Harkins for turning > these around quickly.) Very good Dan... Thanks... Some comments: ---------------------------------------------------------------------- * D-H tests for IKEv2 (Tero Kivinen) ... - tests are required if using ECDH or reusing public keys or ^^ using groups with a small subgroup. ---------------------------------------------------------------------- That "or" needs to be "and". I.e. test are required if using ECDH and reusing public keys. I.e. both are required. ---------------------------------------------------------------------- - Jabber! Yaron says "this is true already." ---------------------------------------------------------------------- I think that reply was to answer to Paul's comment that the draft should support different types of groups we have out there. -- kivinen@iki.fi From kivinen@iki.fi Tue Mar 12 12:49:18 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652B611E8165 for ; Tue, 12 Mar 2013 12:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCakpFmF2K2d for ; Tue, 12 Mar 2013 12:49:18 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 91A9911E8118 for ; Tue, 12 Mar 2013 12:49:17 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r2CJnEgG025553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Mar 2013 21:49:14 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r2CJnEm6005202; Tue, 12 Mar 2013 21:49:14 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20799.34490.611737.922474@fireball.kivinen.iki.fi> Date: Tue, 12 Mar 2013 21:49:14 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Subject: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 19:49:18 -0000 Actually I verified the fragmentation support from Finland, and they said it was requested, but it is not in any product yet, and as Paul Wouters already commented to list that the problem with some implementations sending fragmentation regardless whether it was negotiated or not has already been fixed, I requirement to implement this quickly has gone... Anyways, if there is already more implementations doing IKE framentation, it might be good idea to think whether we should standardize that. On the other hand I am not sure if they are well enough documented so that different implementations actually talk each other... Anyways we should most likely act fastly if we want to get this fixed for IKEv2. -- kivinen@iki.fi From kivinen@iki.fi Tue Mar 12 12:56:33 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B39711E80FC for ; Tue, 12 Mar 2013 12:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cI09e6qC8PJ0 for ; Tue, 12 Mar 2013 12:56:31 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0E111E80FE for ; Tue, 12 Mar 2013 12:56:25 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r2CJuNBI025626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Mar 2013 21:56:23 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r2CJuNAg019086; Tue, 12 Mar 2013 21:56:23 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20799.34918.969821.935296@fireball.kivinen.iki.fi> Date: Tue, 12 Mar 2013 21:56:22 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Subject: [IPsec] Signature authentication in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 19:56:33 -0000 In the meeting I did not remember what was the name the PKIX had for the signature blob, and in my slides written at midnight Sunday evening, I said SubjectPublicKeyInfo, so here I am to provide some correct information... So the thing is what is both in the signatureAlgorithm and SubjectPublicKeyInfo, i.e. the AlgorithmI?dentifier: AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } I.e where there algorithm is the OID we currently have in the draft-kivinen-ipsecme-signature-auth, and the parameters is the one is required to get the RSASSA-PSS to work. Anybody has objection to do it this way? -- kivinen@iki.fi From paul.hoffman@vpnc.org Tue Mar 12 13:20:27 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5924411E8114 for ; Tue, 12 Mar 2013 13:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G53G9+GQIT29 for ; Tue, 12 Mar 2013 13:20:27 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CB89611E80F3 for ; Tue, 12 Mar 2013 13:20:26 -0700 (PDT) Received: from dhcp-6061.meeting.ietf.org (dhcp-6061.meeting.ietf.org [130.129.96.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r2CKKOV0099581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Mar 2013 13:20:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <20799.34117.86998.862225@fireball.kivinen.iki.fi> Date: Tue, 12 Mar 2013 16:20:22 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <0A7279E5-312A-4535-89C4-C1AF06C02DC3@vpnc.org> <20799.34117.86998.862225@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1499) Cc: IPsecme WG Subject: Re: [IPsec] Preliminary minutes from today's meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 20:20:27 -0000 Both things are fixed and uploaded. --Paul Hoffman From mglt.ietf@gmail.com Tue Mar 12 13:21:15 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E026611E8141 for ; Tue, 12 Mar 2013 13:21:15 -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=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdezwxKevvbe for ; Tue, 12 Mar 2013 13:21:15 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 953ED11E8108 for ; Tue, 12 Mar 2013 13:21:14 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id r6so276451wey.5 for ; Tue, 12 Mar 2013 13:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PYVFRN92HXpklSkkY7CNiF7LVLgniay+AFEKP3PFlBk=; b=TwXgYTo4vj0u6+ArFwp8Lxk3a2tWuwIhTd9pyxAxAPfRgVIwylL1TfWkNN+LGVWiaU hndKEhWsLAEPOnDxfo+AhJSSh7a3uxTXrRQp72Nq29W+gAXvrGxLV3NViTbD9joHVb5U TCbVTESt4ytmI61BKW7Onsh0MsZ81fxML99ziPlaFalYOZD10DcfEjIpjDkGYWpkjncd sk9qDdDaoz+8drf00tnmXIzll74LitwGRcRuO7cL2B0Rgqy5iyZr7HEx903hBTIu2dPH hOS47jnTeqZn+ov0kjuAH3IKSPxF5iN67Dhuj82E2tHzeiyolFf55dBCS7JRFZI1ZX8/ xWBw== MIME-Version: 1.0 X-Received: by 10.180.94.133 with SMTP id dc5mr2531563wib.1.1363119673779; Tue, 12 Mar 2013 13:21:13 -0700 (PDT) Received: by 10.194.167.106 with HTTP; Tue, 12 Mar 2013 13:21:13 -0700 (PDT) In-Reply-To: <20799.34117.86998.862225@fireball.kivinen.iki.fi> References: <0A7279E5-312A-4535-89C4-C1AF06C02DC3@vpnc.org> <20799.34117.86998.862225@fireball.kivinen.iki.fi> Date: Tue, 12 Mar 2013 21:21:13 +0100 Message-ID: From: Daniel Migault To: Tero Kivinen Content-Type: multipart/alternative; boundary=f46d04462e66f12c9704d7c0074e Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Preliminary minutes from today's meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 20:21:16 -0000 --f46d04462e66f12c9704d7c0074e Content-Type: text/plain; charset=ISO-8859-1 Hi, RFC XYZ is RFC5566. Thanks for the minutes. BR, Daniel On Tue, Mar 12, 2013 at 8:43 PM, Tero Kivinen wrote: > Paul Hoffman writes: > > ...are at http://www.ietf.org/proceedings/86/minutes/minutes-86-ipsecme > > > > Please send changes *to the minutes* to the list. If you want to > > discuss something that was discussed in the minutes, please start a > > new mail thread. Thanks! (And thanks to Dan Harkins for turning > > these around quickly.) > > Very good Dan... Thanks... Some comments: > > ---------------------------------------------------------------------- > * D-H tests for IKEv2 (Tero Kivinen) > ... > - tests are required if using ECDH or reusing public keys or > ^^ > using groups with a small subgroup. > ---------------------------------------------------------------------- > > That "or" needs to be "and". I.e. test are required if using ECDH and > reusing public keys. I.e. both are required. > > ---------------------------------------------------------------------- > - Jabber! Yaron says "this is true already." > ---------------------------------------------------------------------- > > I think that reply was to answer to Paul's comment that the draft > should support different types of groups we have out there. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --f46d04462e66f12c9704d7c0074e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
Hi,=A0
RFC XYZ is RFC=
5566. Thanks for the minutes.


BR, 
Daniel


On Tue, Mar 12, 2013 at 8:43 PM, Tero Kivinen <kivinen@iki.fi> = wrote:
Paul Hoffman writes:
> ...are at http://www.ietf.org/proceedings/86/minutes/= minutes-86-ipsecme
>
> Please send changes *to the minutes* to the list. If you want to
> discuss something that was discussed in the minutes, please start a > new mail thread. Thanks! (And thanks to Dan Harkins for turning
> these around quickly.)

Very good Dan... Thanks... Some comments:

----------------------------------------------------------------------
=A0 * D-H tests for IKEv2 (Tero Kivinen)
...
=A0 =A0 - tests are required if using ECDH or reusing public keys or
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0^^
=A0 =A0 =A0 using groups with a small subgroup.
----------------------------------------------------------------------

That "or" needs to be "and". I.e. test are required if = using ECDH and
reusing public keys. I.e. both are required.

----------------------------------------------------------------------
=A0 =A0 - Jabber! Yaron says "this is true already."
----------------------------------------------------------------------

I think that reply was to answer to Paul's comment that the draft
should support different types of groups we have out there.
--
kivinen@iki.fi
_____________________= __________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec



--
= Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
--f46d04462e66f12c9704d7c0074e-- From sfluhrer@cisco.com Tue Mar 12 13:26:37 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEC611E81A0 for ; Tue, 12 Mar 2013 13:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+o7iIKQ+ep8 for ; Tue, 12 Mar 2013 13:26:36 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 317FC11E8187 for ; Tue, 12 Mar 2013 13:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2232; q=dns/txt; s=iport; t=1363119986; x=1364329586; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=p8fB2RqdlRcb+CJcChXd0fPGPVjfevrFrDwDs0EMYsQ=; b=Hm2PMM5v7D4FQbWT7VdM7BCdvDC+4YTVoJqUlrbfwWEHFlNYzJzKgUq+ iRLGsxIj3h78aBlcb2QMNSUadkUrcZtt+tB3r3/bCCdfWdCt8uAIsuGYG JKLJhaU32ZQNGxqEr9fup3NcNuFNXfib+J0lxIfLAXXPfU4wxVcROa29j A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOGNP1GtJV2d/2dsb2JhbABDxGqBSxZ0gikBAQEEAQEBNzQLDAQCAQgRBAEBCxQJBycLFAkIAgQBDQUIAYgLDLFUj1wXjVyBACYLBwaCWWEDp0yDCoFzNQ X-IronPort-AV: E=Sophos;i="4.84,833,1355097600"; d="scan'208";a="186749639" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 12 Mar 2013 20:26:25 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2CKQPJw014575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 20:26:25 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 15:26:25 -0500 From: "Scott Fluhrer (sfluhrer)" To: Tero Kivinen , Paul Hoffman Thread-Topic: [IPsec] Preliminary minutes from today's meeting Thread-Index: AQHOH1oFnR+8eGG2dU6fw65DoIPJSpiif4aQ Date: Tue, 12 Mar 2013 20:26:25 +0000 Message-ID: References: <0A7279E5-312A-4535-89C4-C1AF06C02DC3@vpnc.org> <20799.34117.86998.862225@fireball.kivinen.iki.fi> In-Reply-To: <20799.34117.86998.862225@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Preliminary minutes from today's meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 20:26:37 -0000 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Tero Kivinen > Sent: Tuesday, March 12, 2013 3:43 PM > To: Paul Hoffman > Cc: IPsecme WG > Subject: [IPsec] Preliminary minutes from today's meeting >=20 > Paul Hoffman writes: > > ...are at > > http://www.ietf.org/proceedings/86/minutes/minutes-86-ipsecme > > > > Please send changes *to the minutes* to the list. If you want to > > discuss something that was discussed in the minutes, please start a > > new mail thread. Thanks! (And thanks to Dan Harkins for turning these > > around quickly.) >=20 > Very good Dan... Thanks... Some comments: >=20 > ---------------------------------------------------------------------- > * D-H tests for IKEv2 (Tero Kivinen) > ... > - tests are required if using ECDH or reusing public keys or > ^^ > using groups with a small subgroup. > ---------------------------------------------------------------------- >=20 > That "or" needs to be "and". I.e. test are required if using ECDH and reu= sing > public keys. I.e. both are required. Actually, the condition is "reusing public keys AND (ECDH OR groups with a = small subgroup)" That is, - If you're not reusing public keys, well, the attacker can learn something= about the DH private key that you used when negotiating with him, however = that doesn't tell him about what you used on any other SA - If you are reusing public keys, then he can learn a lot of information wi= th ECDH, and some information with a MODP group with a small subgroup, by i= njecting an illegal value, and seeing how the other side reacts (that is, w= hat keys he derives). >=20 > ---------------------------------------------------------------------- > - Jabber! Yaron says "this is true already." > ---------------------------------------------------------------------- >=20 > I think that reply was to answer to Paul's comment that the draft should > support different types of groups we have out there. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Tue Mar 12 13:32:34 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9207011E8179 for ; Tue, 12 Mar 2013 13:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.829 X-Spam-Level: X-Spam-Status: No, score=-100.829 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8YYgYWGPzWH for ; Tue, 12 Mar 2013 13:32:34 -0700 (PDT) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id CE6F811E8168 for ; Tue, 12 Mar 2013 13:32:33 -0700 (PDT) Received: by mail-ea0-f179.google.com with SMTP id f15so90075eak.38 for ; Tue, 12 Mar 2013 13:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=N9La+G7OaPmdDGtBTzPU2rBMiwPm8S5v9ObwnWliI8o=; b=0yoldcPpioNM00BHAwgqBzEm92k5wqEgmd9OIHAUgzZVflBup9vTiPaOeXP7hHCm46 jvzVoxVoCo32ByYq6mVcVdLpxrhTaJ0+21nv/7l6XBzYgskAJ0NYa3oV8phWkKZCFiXM dJDXnfl1dEaNtkfOStDN9UM3XkGUoVUffRbNEbaCv7VwYnXNu4A+/nQgHoo1djGMxJYc TF5FTn7pQGBiEJZ+mEkDVCDiiYMLmsUqycEhRd1aS+KgcuCFZHm+r0Cq9t9AU2dy4sRN 57IGgERCch/NqkOpuM5j8//PGtM7AMtvg5t5H4dPMNvjXMVq0eiZmhDN7J2aF+ur6u3m PHpA== X-Received: by 10.14.194.198 with SMTP id m46mr51311973een.8.1363120352933; Tue, 12 Mar 2013 13:32:32 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-176-129-128.red.bezeqint.net. [79.176.129.128]) by mx.google.com with ESMTPS id h5sm31864531eem.1.2013.03.12.13.32.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 13:32:32 -0700 (PDT) Message-ID: <513F90DD.8080403@gmail.com> Date: Tue, 12 Mar 2013 22:32:29 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Scott Fluhrer (sfluhrer)" References: <0A7279E5-312A-4535-89C4-C1AF06C02DC3@vpnc.org> <20799.34117.86998.862225@fireball.kivinen.iki.fi> In-Reply-To: Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Paul Hoffman , Tero Kivinen Subject: Re: [IPsec] Preliminary minutes from today's meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 20:32:34 -0000 And to clarify my cryptic comment below, I meant that the draft already covers all DH groups currently specified for IKEv2 (i.e. those that have an IANA allocation plus the new Brainpool stuff). I cannot confirm - but maybe Scott can - that we cover any weird curve that's ever crossed DJB's mind. Thanks, Yaron On 03/12/2013 10:26 PM, Scott Fluhrer (sfluhrer) wrote: > > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Tero Kivinen >> Sent: Tuesday, March 12, 2013 3:43 PM >> To: Paul Hoffman >> Cc: IPsecme WG >> Subject: [IPsec] Preliminary minutes from today's meeting >> >> Paul Hoffman writes: >>> ...are at >>> http://www.ietf.org/proceedings/86/minutes/minutes-86-ipsecme >>> >>> Please send changes *to the minutes* to the list. If you want to >>> discuss something that was discussed in the minutes, please start a >>> new mail thread. Thanks! (And thanks to Dan Harkins for turning these >>> around quickly.) >> >> Very good Dan... Thanks... Some comments: >> >> ---------------------------------------------------------------------- >> * D-H tests for IKEv2 (Tero Kivinen) >> ... >> - tests are required if using ECDH or reusing public keys or >> ^^ >> using groups with a small subgroup. >> ---------------------------------------------------------------------- >> >> That "or" needs to be "and". I.e. test are required if using ECDH and reusing >> public keys. I.e. both are required. > > Actually, the condition is "reusing public keys AND (ECDH OR groups with a small subgroup)" > > That is, > > - If you're not reusing public keys, well, the attacker can learn something about the DH private key that you used when negotiating with him, however that doesn't tell him about what you used on any other SA > > - If you are reusing public keys, then he can learn a lot of information with ECDH, and some information with a MODP group with a small subgroup, by injecting an illegal value, and seeing how the other side reacts (that is, what keys he derives). > >> >> ---------------------------------------------------------------------- >> - Jabber! Yaron says "this is true already." >> ---------------------------------------------------------------------- >> >> I think that reply was to answer to Paul's comment that the draft should >> support different types of groups we have out there. >> -- >> kivinen@iki.fi >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From yaronf.ietf@gmail.com Tue Mar 12 13:40:45 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0665021F8BBD for ; Tue, 12 Mar 2013 13:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.829 X-Spam-Level: X-Spam-Status: No, score=-100.829 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Dv-9T+k3lKH for ; Tue, 12 Mar 2013 13:40:44 -0700 (PDT) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB4321F89AE for ; Tue, 12 Mar 2013 13:40:44 -0700 (PDT) Received: by mail-ea0-f178.google.com with SMTP id g14so97137eak.37 for ; Tue, 12 Mar 2013 13:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Uon0Vz0iQMsA0eIYAQkD7y/XKXMWn7lFbkKm/O8FKxs=; b=Ts2crBt7/xJZGjgk6RVep8PZuglU0WVPVgiW6n4jo1C5egnW4g+khiZRyVsSkp/OyN JSDam9O+ko/kgfsui2GpkCO26h94G930wbBNF8H0AUdtMwjxodWmK6Z5+R0Mdcj5rhTt nGbVK/mbvJ19gTa+W2RGoChju4DDz0wOkytRWtl0nfcqWnB01bMNteqmA8+8gnsbMQO4 VCa0OcekL2SQvSmqW3+E3aFkDwsVUtbcUtZIXtOwDfnGrmMbaxooBsmpvvIV8UsqXo5q BEm4TdVfN+WolU35THlE5Szlg5cMarBJfSoE0EIHjcucdD4Uw8fg9ritemLzs3WfjESk CX0w== X-Received: by 10.15.100.202 with SMTP id bn50mr51343955eeb.36.1363120843383; Tue, 12 Mar 2013 13:40:43 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-176-129-128.red.bezeqint.net. [79.176.129.128]) by mx.google.com with ESMTPS id 3sm31896080eej.6.2013.03.12.13.40.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 13:40:42 -0700 (PDT) Message-ID: <513F92C7.8080507@gmail.com> Date: Tue, 12 Mar 2013 22:40:39 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Tero Kivinen References: <513F404E.5060608@gmail.com> <20799.27003.633105.446538@fireball.kivinen.iki.fi> In-Reply-To: <20799.27003.633105.446538@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] DH Tests draft - failure behavior X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 20:40:45 -0000 Hi Tero, I think this case should be handled exactly like any badly formatted message. Referring to http://tools.ietf.org/html/rfc5996#section-2.21.1, we did not mandate sending errors back, but it is implied in the text. And yes, the receiver is free to ignore these errors for the reasons you cite. In fact there's no obvious remedial action anyway, similarly to "invalid syntax", the error basically indicates a bug. So sending this error just helps in debugging the sender and nothing more. But IMHO this is still a good reason to send it. Thanks, Yaron On 03/12/2013 07:44 PM, Tero Kivinen wrote: > Yaron Sheffer writes: >> Following up on the discussion we just had: >> >> Paul raised the question whether we should respond with an error message >> in case any of the tests fail. We know from many examples that errors >> can reveal secret information. >> >> However in this particular case: >> >> - All IKEv2 DH groups are public information. >> - All of the proposed tests only depend on public information, plus the >> information received from the sender in the clear. In other words, the >> test could just as well be performed by an eavesdropper. >> >> The only thing that such an error message does reveal is that the >> receiver implements the test, but this is something that an attacker can >> find out anyway. >> >> Which is why I think we should treat such failures as a normal syntax >> error, and respond with an error message, as a courtesy to the sender. >> >> We should make these considerations explicit in the draft, specifically >> that the groups are well known. > > On the other hand failure there means we didn't manage to negotiate > shared secret, thus the whatever error message we sent out must be > unauthenticated. The recipient of such unauthenticated notify cannot > act directly on it, as attacker might have sent it instead of the real > peer, and real peer might actually take some time to do the checks and > other calculations before answering. Befcause of this sending the > notification does not help that much, it only opens new way to do DoS > attack. As this error cannot happen in valid implementations, it is > always either attack or implementation working incorrectly, I see no > point of making special code for error messages in that case. > > My recommendation is that the recipient will simply silently ignore > the IKE_SA_INIT packet having invalid KE payload. It MAY continue > keep setting up the SA, i.e. see if there is properly formatted and > generated KE payload in the future. Otherwise the attacker could again > do DoS attack against the peer, by sending there IKE_SA_INIT response > with invalid KE payload and cause inititor to drop the connection > before the real responder have time to reply. > From svanru@gmail.com Wed Mar 13 06:22:24 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E84E21F8D35 for ; Wed, 13 Mar 2013 06:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.703 X-Spam-Level: * X-Spam-Status: No, score=1.703 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfCmCHTtyr+C for ; Wed, 13 Mar 2013 06:22:23 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 53ADC21F8A43 for ; Wed, 13 Mar 2013 06:22:23 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id eb20so1107978lab.3 for ; Wed, 13 Mar 2013 06:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=83gy9oI+exNmCpdpbUNPyJzfMa22I+F7RuzN2UVIU14=; b=s3zGdFo88FIr9jigcclo3jXi2Hk76sYM1ymhOWKC9vYXvwAeUy/NzpbKlRdq9ZrLXk LXGgdzs7S6zxv0HwX1qaVp1yP3vGpwcgoPEQjSkso0+HTB2Oy2FpNaQKECTIO12pa6As Ci/OqRYwmrTc6ip4jOZiXoV1VgiFQ7B7/TQpY5qgXzBtl7Mnrw04j8KTz1+ye/h+gOEb qlM9sybbDkKNN0VMbpaMX/CE3v0/HbJADjzX4wYMCbXaaGmdovfQxfDnajM9ErKgyOTg Jv6YAgz4lxV5fPQVFSkjn8UzZSxepJfjehOAHbvKqEV/x9YcYo/ExxoxXL4/bczpqYSM bNqQ== X-Received: by 10.152.46.131 with SMTP id v3mr17550371lam.57.1363180942289; Wed, 13 Mar 2013 06:22:22 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPS id o11sm1328202lbu.6.2013.03.13.06.22.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 13 Mar 2013 06:22:21 -0700 (PDT) Message-ID: <294A12724CB849D2A33F7F80CC82426A@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" , References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> Date: Wed, 13 Mar 2013 17:22:31 +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 Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 13:22:24 -0000 Hi, > Anyways, if there is already more implementations doing IKE > framentation, it might be good idea to think whether we should > standardize that. On the other hand I am not sure if they are well > enough documented so that different implementations actually talk each > other... We support IKEv1 fragmentation based on documentation found at msdn.microsoft.com. We are able to interoperate with both Microsoft and Cisco. > Anyways we should most likely act fastly if we want to get this fixed > for IKEv2. As for IKEv2, I don't know how Cisco is doing fragmentation in this case (it seems to have support for it), but if it is done similarly to IKEv1, than I prefer our own solution - draft-smyslov-ipsecme-ikev2-fragmentation. The main difference is that in Microsoft/Cisco solution (for IKEv1) the whole encrypted ISAKMP message is fragmented, leaving each fragment unauthanticated untill message get reassembled and its authentity could be verivied. This opens door for a very simple DoS attack on receiver. In our proposal each fragment is encrypted and authenticated individually, that allows receiver to distinguish valid fragments from bogus, thus preventing from abovementioned DoS attack. And, of course, we have implemented this solution in our products. And, of course, we are intersted in doing IKEv2 fragmentation in standard, interoperable way (based either on our proposal or smth else). Regards, Valery Smyslov. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Wed Mar 13 06:43:47 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDB721F87F9 for ; Wed, 13 Mar 2013 06:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.064 X-Spam-Level: X-Spam-Status: No, score=-99.064 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uf9QGIm2lSyt for ; Wed, 13 Mar 2013 06:43:46 -0700 (PDT) Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADC021F87AC for ; Wed, 13 Mar 2013 06:43:46 -0700 (PDT) Received: by mail-bk0-f50.google.com with SMTP id jg9so465914bkc.37 for ; Wed, 13 Mar 2013 06:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZN7CTI2Fpqq5SR9iJKt12a2CBTeEJBh5lNLwNtySRiY=; b=Qs7t8G7u4FtYW4M7YL+isqDYr+84wZLtJrXh9XetFuboqSqDLeyH0xcyGgRqmZmS7M Acyi+FMOagSgXf7uvR5idL0Qi5BbQkK3O7n2/VFTe2BAhKBBtHNrCSxwwgP2/ttEDEqL knhJl6pNjCJP8yOh1HBGS31w1lYfh+ecXnoiiIB5r8l/I16YM9SbmshLSzAOLIUfVd/v MOxQt8Eq0CZfxVV+Akew8Gu5Zrjo81x7epv0m9K/tkggH55At54N/Lo5nY7Lq7ROJp1p Tw2cuBjeBVjR5N4u03XJqRHII5oBKgXMlajw5jyrJNQaa8OizVx/k2AU+NqXrcdXmgXg M3PQ== X-Received: by 10.205.120.133 with SMTP id fy5mr7664992bkc.87.1363182225466; Wed, 13 Mar 2013 06:43:45 -0700 (PDT) Received: from [10.0.0.14] (89-139-62-92.bb.netvision.net.il. [89.139.62.92]) by mx.google.com with ESMTPS id x18sm6034540bkw.4.2013.03.13.06.43.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Mar 2013 06:43:44 -0700 (PDT) Message-ID: <51408287.7080207@gmail.com> Date: Wed, 13 Mar 2013 15:43:35 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Valery Smyslov References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> In-Reply-To: <294A12724CB849D2A33F7F80CC82426A@buildpc> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 13:43:47 -0000 Hi Valery, I believe the DoS argument is incorrect, because the message we are most worried about (most likely to get fragmented) is IKE_AUTH, and at this point both peers are not yet authenticated, of course. So fragments and messages can be encrypted but cannot be authenticated. Thus, an attacker can send any number of seemingly valid fragments. Let me know if I'm missing anything. Thanks, Yaron On 03/13/2013 03:22 PM, Valery Smyslov wrote: > Hi, > >> Anyways, if there is already more implementations doing IKE >> framentation, it might be good idea to think whether we should >> standardize that. On the other hand I am not sure if they are well >> enough documented so that different implementations actually talk each >> other... > > We support IKEv1 fragmentation based on documentation found at > msdn.microsoft.com. > We are able to interoperate with both Microsoft and Cisco. > >> Anyways we should most likely act fastly if we want to get this fixed >> for IKEv2. > > As for IKEv2, I don't know how Cisco is doing fragmentation in this case > (it seems to have support for it), but if it is done similarly to IKEv1, > than I prefer our own solution - draft-smyslov-ipsecme-ikev2-fragmentation. > The main difference is that in Microsoft/Cisco solution (for IKEv1) > the whole encrypted ISAKMP message is fragmented, > leaving each fragment unauthanticated untill message get reassembled > and its authentity could be verivied. This opens door for > a very simple DoS attack on receiver. > > In our proposal each fragment is encrypted and authenticated > individually, that allows receiver to distinguish valid fragments > from bogus, thus preventing from abovementioned DoS attack. > > And, of course, we have implemented this solution in our products. > > And, of course, we are intersted in doing IKEv2 fragmentation > in standard, interoperable way (based either on our proposal or > smth else). > > Regards, > Valery Smyslov. > >> -- >> kivinen@iki.fi >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From paul@nohats.ca Wed Mar 13 06:51:20 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E8521F8D07 for ; Wed, 13 Mar 2013 06:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMeaW9fqmoJW for ; Wed, 13 Mar 2013 06:51:19 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8443D21F8CF7 for ; Wed, 13 Mar 2013 06:51:19 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZQvbJ1WVqz147; Wed, 13 Mar 2013 09:51:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id EgFSzwYH8AqC; Wed, 13 Mar 2013 09:51:06 -0400 (EDT) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 13 Mar 2013 09:51:05 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 6946B80860; Wed, 13 Mar 2013 09:51:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 54986804F3; Wed, 13 Mar 2013 09:51:05 -0400 (EDT) Date: Wed, 13 Mar 2013 09:51:05 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: <294A12724CB849D2A33F7F80CC82426A@buildpc> Message-ID: References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 13:51:20 -0000 On Wed, 13 Mar 2013, Valery Smyslov wrote: > As for IKEv2, I don't know how Cisco is doing fragmentation in this case > (it seems to have support for it), but if it is done similarly to IKEv1, > than I prefer our own solution - draft-smyslov-ipsecme-ikev2-fragmentation. > The main difference is that in Microsoft/Cisco solution (for IKEv1) > the whole encrypted ISAKMP message is fragmented, > leaving each fragment unauthanticated untill message get reassembled > and its authentity could be verivied. This opens door for > a very simple DoS attack on receiver. How is that a DOS attack? In our implementation of the IKEv1 fragmentation, we limit the number of fragments to 16. We will only need to do any crypto when we received the IKE packet marked as "last". Then we do crypto once on the assembled packet and throw it away when crypto fails. > In our proposal each fragment is encrypted and authenticated > individually, that allows receiver to distinguish valid fragments > from bogus, thus preventing from abovementioned DoS attack. But I can send lots of small forged fragments and you will do lots of crypto on them for _each_ forged fragment. I think you will end up using a lot more cpu and the attacker needs a lot less bandwidth. I actually do like the IKEv1 version. It's very simple. And uses the exact same code path apart from a little buffer where we store some fragments (with sane limits). The only oddness is that fragmentation ID that serves no purpose, as you cannot really have two different packets fragmented in flight for a single exchange. (well you can, but they are going to be identical anyway) While implementing the IKEv1 version, I did wonder about what should trigger fragmentation. For instance, if both parties have send and received the vendorid, and one side sends fragments, should the other side fully indepedantly wait for failure/retransmit before using fragments, or take the hint that if the path is broken one way, it is likely broken in the other way as well? It seems that being a little aggressive here can really help the IPsec SA to establish much faster - especially since our own retransmit time is 20 seconds, which is something we are now consideraing lowering a lot. Our implementation also does not handle the first packet of an exchange to be fragmented, because we have no state to store the fragments for. In practise this does not matter because the first packet is never large enough to need fragmentation. Paul From svanru@gmail.com Wed Mar 13 07:06:37 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B60121F8D1B for ; Wed, 13 Mar 2013 07:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.702 X-Spam-Level: * X-Spam-Status: No, score=1.702 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-NKxqzZ+qjE for ; Wed, 13 Mar 2013 07:06:36 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3640D21F8D42 for ; Wed, 13 Mar 2013 07:06:35 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id eb20so1170690lab.3 for ; Wed, 13 Mar 2013 07:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:cc:references:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:x-mimeole; bh=5LDQq7LMkhqaWiZ8hAjhNVYQRXjafbxF1S4xRxmeB8g=; b=xP/tZdfoBqVlcnY3Jd4hnZfLRzJvwQNOGkHPGUELUtn0pLP/SGXxpYrb9NLSUs9ICo qlC9qu8MqJTg+92Er6k0PBISfIUaXKspc22P9XPL4F2uk4dcjBVgWmh4pClk8N0eRqML Atd/oyI4sLhOhthEnzekWyeflixHGOsMy+IaUDFPjW31LDY0ZYVHkycLj3U+DFIDkw+L e8sm+QuhfEWHuOvwr8WaZSqkZylU/giV4usl51GIy6h/IpztfwlBKZpr+gzvEHQESZc8 XlqBh67RMfOVj/zvN4fuisb7aWzgFSjpX/Yk8UdC+cJ9J6Uj3/4shN7xFWQDNVkHb9ua +dSw== X-Received: by 10.152.46.12 with SMTP id r12mr17744775lam.15.1363183593118; Wed, 13 Mar 2013 07:06:33 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPS id pk1sm11364281lab.0.2013.03.13.07.06.31 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 13 Mar 2013 07:06:32 -0700 (PDT) Message-ID: <3028CF35E60A40068CE70EB7BB0BDEF1@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> <51408287.7080207@gmail.com> Date: Wed, 13 Mar 2013 18:06:45 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1255"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 14:06:37 -0000 Hi Yaron, > I believe the DoS argument is incorrect, because the message we are most > worried about (most likely to get fragmented) is IKE_AUTH, and at this > point both peers are not yet authenticated, of course. So fragments and > messages can be encrypted but cannot be authenticated. Thus, an attacker > can send any number of seemingly valid fragments. > > Let me know if I'm missing anything. I agree that term "authenticated" is a bit misleading here. The better term would be "integrity protected". In our proposal receiver can be absolutely sure that each fragment comes from the very peer he/she exchanged DH exponents and calculated shared secret with. All fragments which ICV cannot be verified are discarded and don't prevent communication with real peer in any way. Hope this helps. Regards, Valery. > Thanks, > Yaron > > On 03/13/2013 03:22 PM, Valery Smyslov wrote: >> Hi, >> >>> Anyways, if there is already more implementations doing IKE >>> framentation, it might be good idea to think whether we should >>> standardize that. On the other hand I am not sure if they are well >>> enough documented so that different implementations actually talk each >>> other... >> >> We support IKEv1 fragmentation based on documentation found at >> msdn.microsoft.com. >> We are able to interoperate with both Microsoft and Cisco. >> >>> Anyways we should most likely act fastly if we want to get this fixed >>> for IKEv2. >> >> As for IKEv2, I don't know how Cisco is doing fragmentation in this case >> (it seems to have support for it), but if it is done similarly to IKEv1, >> than I prefer our own solution - >> draft-smyslov-ipsecme-ikev2-fragmentation. >> The main difference is that in Microsoft/Cisco solution (for IKEv1) >> the whole encrypted ISAKMP message is fragmented, >> leaving each fragment unauthanticated untill message get reassembled >> and its authentity could be verivied. This opens door for >> a very simple DoS attack on receiver. >> >> In our proposal each fragment is encrypted and authenticated >> individually, that allows receiver to distinguish valid fragments >> from bogus, thus preventing from abovementioned DoS attack. >> >> And, of course, we have implemented this solution in our products. >> >> And, of course, we are intersted in doing IKEv2 fragmentation >> in standard, interoperable way (based either on our proposal or >> smth else). >> >> Regards, >> Valery Smyslov. >> >>> -- >>> kivinen@iki.fi >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec From svanru@gmail.com Wed Mar 13 07:31:06 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E6F21F8DEB for ; Wed, 13 Mar 2013 07:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=2.651, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jTvKCnO9Qqu for ; Wed, 13 Mar 2013 07:31:05 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E1CA121F8DDD for ; Wed, 13 Mar 2013 07:31:04 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id n8so1000665lbj.31 for ; Wed, 13 Mar 2013 07:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:cc:references:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:x-mimeole; bh=u6xTTP5OACqjacGXWTpAdqb8eKXXryillQ2WYv81np4=; b=MeJ+a1ZKBYyK0xrq0UjEzxQ3rSzxdLJK+CPhaC6cowvHTuX0ze7nq+zE9240mUDAV6 2ed5BXiNxoBaRyd+xNIGQ+EloqrEcT7sKQTlSiLBB5E1hnWDK7hQSNABv1yyqSPzHnQ0 Xh8mYRX6RS24uvRXSxbE6z6RopaGTwMdUiG5DmsR2nY2bPM5jDJPWUDSxJF5DMAdOQ2M +eAkt356FdKSUU2JuKMe9ZRYopDitnHzlZmw56t8K56VCB6MX0fNULef1RjvKFcwvKKb laKTKl5up8Hmvqh2GMRb/OJR24rnEIMRs22N396A9k3eVEbZVnBGNTOuBiyBOfMMIB8Y aEYA== X-Received: by 10.152.104.199 with SMTP id gg7mr17645363lab.14.1363185059558; Wed, 13 Mar 2013 07:30:59 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPS id fm8sm6975556lbb.17.2013.03.13.07.30.57 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 13 Mar 2013 07:30:58 -0700 (PDT) Message-ID: <4C4F5DE0838E4DCFBAE31A02D7ED5D33@buildpc> From: "Valery Smyslov" To: "Paul Wouters" References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> Date: Wed, 13 Mar 2013 18:31:12 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 14:31:06 -0000 Hi Paul, >> As for IKEv2, I don't know how Cisco is doing fragmentation in this case >> (it seems to have support for it), but if it is done similarly to IKEv1, >> than I prefer our own solution - >> draft-smyslov-ipsecme-ikev2-fragmentation. >> The main difference is that in Microsoft/Cisco solution (for IKEv1) >> the whole encrypted ISAKMP message is fragmented, >> leaving each fragment unauthanticated untill message get reassembled >> and its authentity could be verivied. This opens door for >> a very simple DoS attack on receiver. > > How is that a DOS attack? In our implementation of the IKEv1 > fragmentation, we limit the number of fragments to 16. We will > only need to do any crypto when we received the IKE packet > marked as "last". Then we do crypto once on the assembled packet > and throw it away when crypto fails. If attacker sends you a forged fragment, you cannot determine this untill you get reassembled the whole message. When you determine this you have to discard all received fragments (as you don't know which of them is bogus) and wait for retransmission. For attacker it is enough to send you forged fragments with rather low rate to have a good chance to prevent you from communication with your peer. I think this is kind of DoS attack as Initiator is denied to get desired service (IPsec). >> In our proposal each fragment is encrypted and authenticated >> individually, that allows receiver to distinguish valid fragments >> from bogus, thus preventing from abovementioned DoS attack. > > But I can send lots of small forged fragments and you will do lots > of crypto on them for _each_ forged fragment. I think you will end > up using a lot more cpu and the attacker needs a lot less bandwidth. ICV check is (must be) very fast, and you cannot avoid this attack even without fragmentation - attacker can send you forged regular messages and you will have to do ICV check for each of them. I don't think fragmentation makes this worse. > I actually do like the IKEv1 version. It's very simple. And uses > the exact same code path apart from a little buffer where we store > some fragments (with sane limits). The only oddness is that > fragmentation ID that serves no purpose, as you cannot really have > two different packets fragmented in flight for a single exchange. > (well you can, but they are going to be identical anyway) > > While implementing the IKEv1 version, I did wonder about what should > trigger fragmentation. For instance, if both parties have send and > received the vendorid, and one side sends fragments, should the > other side fully indepedantly wait for failure/retransmit before > using fragments, or take the hint that if the path is broken one > way, it is likely broken in the other way as well? It seems that > being a little aggressive here can really help the IPsec SA to > establish much faster - especially since our own retransmit time > is 20 seconds, which is something we are now consideraing lowering > a lot. I think that responder should start replying with fragments immediately after it receives first fragmented message from initiator, but not before this event. It is initiator who is responsible for retransmissions and it is his/her responsibility to switch on fragmentation. > Our implementation also does not handle the first packet of an > exchange to be fragmented, because we have no state to store the > fragments for. In practise this does not matter because the first > packet is never large enough to need fragmentation. We do the same. > Paul Regards, Valery. From paul@nohats.ca Wed Mar 13 07:40:32 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6139621F8C72 for ; Wed, 13 Mar 2013 07:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsTBXO59KwDK for ; Wed, 13 Mar 2013 07:40:31 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id C395621F8A41 for ; Wed, 13 Mar 2013 07:40:31 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZQwhF5j0lz1c4; Wed, 13 Mar 2013 10:40:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id fk6SSK2EpF4U; Wed, 13 Mar 2013 10:40:28 -0400 (EDT) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 13 Mar 2013 10:40:28 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id ADAA080860; Wed, 13 Mar 2013 10:40:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9E1F6804F3; Wed, 13 Mar 2013 10:40:28 -0400 (EDT) Date: Wed, 13 Mar 2013 10:40:28 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: <4C4F5DE0838E4DCFBAE31A02D7ED5D33@buildpc> Message-ID: References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> <4C4F5DE0838E4DCFBAE31A02D7ED5D33@buildpc> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 14:40:32 -0000 On Wed, 13 Mar 2013, Valery Smyslov wrote: >> How is that a DOS attack? In our implementation of the IKEv1 >> fragmentation, we limit the number of fragments to 16. We will >> only need to do any crypto when we received the IKE packet >> marked as "last". Then we do crypto once on the assembled packet >> and throw it away when crypto fails. > > If attacker sends you a forged fragment, you cannot determine this > untill you get reassembled the whole message. When you determine > this you have to discard all received fragments (as you don't know > which of them is bogus) and wait for retransmission. For attacker > it is enough to send you forged fragments with rather low rate > to have a good chance to prevent you from communication with your peer. > > I think this is kind of DoS attack as Initiator is denied to get desired > service (IPsec). But then the attacker has to know the SPI/COOKIES too? So it is an in-path attack. But I see you point. > I think that responder should start replying with fragments > immediately after it receives first fragmented message from initiator, > but not before this event. It is initiator who is responsible > for retransmissions and it is his/her responsibility to > switch on fragmentation. Yes, this case is different for IKEv2. >> Our implementation also does not handle the first packet of an >> exchange to be fragmented, because we have no state to store the >> fragments for. In practise this does not matter because the first >> packet is never large enough to need fragmentation. > > We do the same. So does it make sense to say in the document that the first packet must not be fragmented? Paul From svanru@gmail.com Wed Mar 13 07:51:52 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D623721F8E3A for ; Wed, 13 Mar 2013 07:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.819 X-Spam-Level: X-Spam-Status: No, score=0.819 tagged_above=-999 required=5 tests=[AWL=-0.883, BAYES_00=-2.599, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akZEj8wSErlv for ; Wed, 13 Mar 2013 07:51:52 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 73FA921F8E3D for ; Wed, 13 Mar 2013 07:51:48 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id fo12so1230494lab.28 for ; Wed, 13 Mar 2013 07:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:cc:references:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:x-mimeole; bh=086J1UK3hL5L+58YNZW19iXSH9nnBlHriaUFfNKaUds=; b=e4MJqNsIBXB25UuylQCjZ20f/2ZjGGlMjy1XrWbRWi+a0w1YDE7OfwJF0yJMu3QywH 4G/seCcdC3y7vYKPpyACh1upB1v+E6zPDSXeTGqYBsxhRdm2zYW7hFH9aignAbJQH+C9 xJIpp6qlJQ7LrMd8FY6veabxD4Y6TcvoHxtmIQ/lfqnwiB8G8hma1VCS5H3ei8PUwFes VSTsUoEgDREDk2amtAT8SFol7O/nz5WrMKuWMwD9WPm8rOc+wgAAJAcPOh6FP65X76If t97g0uxJpIOFS45EKothBJo2xsmDHGoqCbD2Ljy2x3XWVxKBxANRZwgEeVE1VyULDO9j zeuw== X-Received: by 10.112.9.231 with SMTP id d7mr7836753lbb.8.1363186307365; Wed, 13 Mar 2013 07:51:47 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPS id fq10sm1156324lbb.14.2013.03.13.07.51.45 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 13 Mar 2013 07:51:46 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> <4C4F5DE0838E4DCFBAE31A02D7ED5D33@buildpc> Date: Wed, 13 Mar 2013 18:52:00 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 14:51:53 -0000 >>> Our implementation also does not handle the first packet of an >>> exchange to be fragmented, because we have no state to store the >>> fragments for. In practise this does not matter because the first >>> packet is never large enough to need fragmentation. >> >> We do the same. > > So does it make sense to say in the document that the first packet > must not be fragmented? If you mean draft-smyslov-ipsecme-ikev2-fragmentation, that limitation must be already there. If it is not clear enough, I'll make it more explicit. Or are you talking about the fictional IETF document (not yet written) describing existing IKEv1 fragmentation? Probably it is better that the authors of that solution document it. Regards, Valery. > Paul From paul@nohats.ca Wed Mar 13 07:58:46 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1C221F8DC9 for ; Wed, 13 Mar 2013 07:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRLsLzLtUAdV for ; Wed, 13 Mar 2013 07:58:46 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3661A21F8DAC for ; Wed, 13 Mar 2013 07:58:46 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZQx5G6sp9zp2; Wed, 13 Mar 2013 10:58:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 2XwmXs2eBNar; Wed, 13 Mar 2013 10:58:41 -0400 (EDT) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 13 Mar 2013 10:58:41 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 1B6F380860; Wed, 13 Mar 2013 10:58:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B436B804F3; Wed, 13 Mar 2013 10:58:40 -0400 (EDT) Date: Wed, 13 Mar 2013 10:58:40 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: Message-ID: References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> <4C4F5DE0838E4DCFBAE31A02D7ED5D33@buildpc> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 14:58:46 -0000 On Wed, 13 Mar 2013, Valery Smyslov wrote: >> So does it make sense to say in the document that the first packet >> must not be fragmented? > > If you mean draft-smyslov-ipsecme-ikev2-fragmentation, that limitation must > be already there. If it is not clear enough, I'll make it more explicit. I have to re-read the draft again, sorry. > Or are you talking about the fictional IETF document (not yet written) > describing existing IKEv1 fragmentation? Probably it is better that > the authors of that solution document it. I don't think any IKEv1 documents will ever be written again? :) Paul From derek@ihtfp.com Tue Mar 12 13:26:39 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E2D11E81A0 for ; Tue, 12 Mar 2013 13:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E85-rnrgs4iK for ; Tue, 12 Mar 2013 13:26:39 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id D603C11E81A5 for ; Tue, 12 Mar 2013 13:26:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id A55F42602B6; Tue, 12 Mar 2013 16:26:31 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 02674-05; Tue, 12 Mar 2013 16:26:30 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 3151A260306; Tue, 12 Mar 2013 16:26:29 -0400 (EDT) Received: from 130.129.84.138 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Tue, 12 Mar 2013 16:26:29 -0400 Message-ID: In-Reply-To: <20799.34490.611737.922474@fireball.kivinen.iki.fi> References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> Date: Tue, 12 Mar 2013 16:26:29 -0400 From: "Derek Atkins" To: "Tero Kivinen" User-Agent: SquirrelMail/1.4.22-2.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a X-Mailman-Approved-At: Wed, 13 Mar 2013 08:04:26 -0700 Cc: ipsec@ietf.org Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 20:26:40 -0000 Mocana's implementation appears to only support fragmentation for IKEv1, not IKEv2. -derek On Tue, March 12, 2013 3:49 pm, Tero Kivinen wrote: > Actually I verified the fragmentation support from Finland, and they > said it was requested, but it is not in any product yet, and as Paul > Wouters already commented to list that the problem with some > implementations sending fragmentation regardless whether it was > negotiated or not has already been fixed, I requirement to implement > this quickly has gone... > > Anyways, if there is already more implementations doing IKE > framentation, it might be good idea to think whether we should > standardize that. On the other hand I am not sure if they are well > enough documented so that different implementations actually talk each > other... > > Anyways we should most likely act fastly if we want to get this fixed > for IKEv2. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From ynir@checkpoint.com Wed Mar 13 16:39:41 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFAF21F8A0C for ; Wed, 13 Mar 2013 16:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.582 X-Spam-Level: X-Spam-Status: No, score=-10.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UO3SPUWEWnOF for ; Wed, 13 Mar 2013 16:39:40 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFCB21F8A08 for ; Wed, 13 Mar 2013 16:39:39 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2DNdZPu004242; Thu, 14 Mar 2013 01:39:35 +0200 X-CheckPoint: {51410D63-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.95]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 01:39:35 +0200 From: Yoav Nir To: Paul Wouters Thread-Topic: [IPsec] IKE fragmentation Thread-Index: AQHOH/pQdHmEPMd7P0SMbddmnpEj3pijlQIAgACRiAA= Date: Wed, 13 Mar 2013 23:39:34 +0000 Message-ID: References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> <4C4F5DE0838E4DCFBAE31A02D7ED5D33@buildpc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.156] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Valery Smyslov , Tero Kivinen Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 23:39:41 -0000 On Mar 13, 2013, at 10:58 AM, Paul Wouters wrote: > On Wed, 13 Mar 2013, Valery Smyslov wrote: >=20 >> Or are you talking about the fictional IETF document (not yet written) >> describing existing IKEv1 fragmentation? Probably it is better that >> the authors of that solution document it. >=20 > I don't think any IKEv1 documents will ever be written again? :) I think that if we make this a working group document, we should add an App= endix that will be informational and describe what people are doing for IKE= v1, including the VendorID and the payload identifier "appropriated" for fr= agments. When I implemented this I used the source of Wireshark to figure out how th= e protocol worked. Pretty poor reverse engineering, but it produced somethi= ng that interoperates. Yoav= From ynir@checkpoint.com Wed Mar 13 16:43:15 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5CD11E8109 for ; Wed, 13 Mar 2013 16:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.583 X-Spam-Level: X-Spam-Status: No, score=-10.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CV0V-An6KcAm for ; Wed, 13 Mar 2013 16:43:15 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9950F11E80E8 for ; Wed, 13 Mar 2013 16:43:14 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2DNhC3a004696; Thu, 14 Mar 2013 01:43:12 +0200 X-CheckPoint: {51410E3C-2-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.95]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 01:43:12 +0200 From: Yoav Nir To: Valery Smyslov Thread-Topic: [IPsec] IKE fragmentation Thread-Index: AQHOH/P+dHmEPMd7P0SMbddmnpEj3pikJ5oA Date: Wed, 13 Mar 2013 23:43:11 +0000 Message-ID: References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> <51408287.7080207@gmail.com> <3028CF35E60A40068CE70EB7BB0BDEF1@buildpc> In-Reply-To: <3028CF35E60A40068CE70EB7BB0BDEF1@buildpc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.156] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <99C4B59579F53648897873573F839A70@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Tero Kivinen Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 23:43:15 -0000 On Mar 13, 2013, at 10:06 AM, Valery Smyslov wrote: > Hi Yaron, >=20 >> I believe the DoS argument is incorrect, because the message we are most= worried about (most likely to get fragmented) is IKE_AUTH, and at this poi= nt both peers are not yet authenticated, of course. So fragments and messag= es can be encrypted but cannot be authenticated. Thus, an attacker can send= any number of seemingly valid fragments. >>=20 >> Let me know if I'm missing anything. >=20 > I agree that term "authenticated" is a bit misleading here. > The better term would be "integrity protected". > In our proposal receiver can be absolutely sure that > each fragment comes from the very peer he/she exchanged > DH exponents and calculated shared secret with. >=20 > All fragments which ICV cannot be verified are discarded > and don't prevent communication with real peer in any way. So in order to get the responder to spend memory resources on storing the f= ragment, the initiator needs to expand CPU resources on completing the D-H = calculation, and calculating integrity protection on the fragment. Makes se= nse. What do you get when you put together the fragments? a decrypted IKE messag= e? Just the list of payloads? Yoav= From paul.hoffman@vpnc.org Thu Mar 14 04:33:34 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7656621F8FD2 for ; Thu, 14 Mar 2013 04:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayianiIYaX9O for ; Thu, 14 Mar 2013 04:33:34 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0395A21F8FCF for ; Thu, 14 Mar 2013 04:33:33 -0700 (PDT) Received: from dhcp-4717.meeting.ietf.org (dhcp-4717.meeting.ietf.org [130.129.71.23]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r2EBXWSP087187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 14 Mar 2013 04:33:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <20799.34490.611737.922474@fireball.kivinen.iki.fi> Date: Thu, 14 Mar 2013 07:33:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> To: IPsecme WG X-Mailer: Apple Mail (2.1499) Subject: [IPsec] Informal poll on IKEv2 { over TCP | fragmentation } X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 11:33:34 -0000 It is seeming that consensus is trending towards "let's document the = fragmentation method some vendors are already doing instead of finishing = IKEv2-over-TCP", but I would like to check that. Please respond to the = informal poll below. --Paul Hoffman - I would prefer the WG to continue working on IKEv2 over TCP - I would prefer the WG to stop working on IKEv2 over TCP and instead = work on standardizing IKEv2 fragmentation - I would prefer the WG to continue working on IKEv2 over TCP and also = work on standardizing IKEv2 fragmentation From ynir@checkpoint.com Thu Mar 14 05:09:58 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E344121F8D0E for ; Thu, 14 Mar 2013 05:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.85 X-Spam-Level: X-Spam-Status: No, score=-7.85 tagged_above=-999 required=5 tests=[AWL=0.150, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzk6Fm2M-ysx for ; Thu, 14 Mar 2013 05:09:57 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3931C21F8F62 for ; Thu, 14 Mar 2013 05:09:57 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2EC9jeX029733; Thu, 14 Mar 2013 14:09:50 +0200 X-CheckPoint: {5141BD2E-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 14:09:45 +0200 From: Yoav Nir To: Paul Hoffman Thread-Topic: [IPsec] Informal poll on IKEv2 { over TCP | fragmentation } Thread-Index: AQHOIKoDiGWFYKwEBE2odkleAjXVZJik9sIA Date: Thu, 14 Mar 2013 12:09:44 +0000 Message-ID: References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.4] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <5C496DD8D27B01448E0299E7BA75D0F4@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Informal poll on IKEv2 { over TCP | fragmentation } X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 12:09:59 -0000 On Mar 14, 2013, at 7:33 AM, Paul Hoffman wrote: > >=20 > It is seeming that consensus is trending towards "let's document the frag= mentation method some vendors are already doing instead of finishing IKEv2-= over-TCP", but I would like to check that. Please respond to the informal p= oll below. >=20 > --Paul Hoffman >=20 >=20 > - I would prefer the WG to continue working on IKEv2 over TCP >=20 > - I would prefer the WG to stop working on IKEv2 over TCP and instead wor= k on standardizing IKEv2 fragmentation >=20 > - I would prefer the WG to continue working on IKEv2 over TCP and also wo= rk on standardizing IKEv2 fragmentation In another meeting, I said that standardizing two ways of achieving the sam= e goal is a failure mode. I still believe that. I also believe that fragmen= tation is easier to fall back on than TCP. IOW an IKE-over-TCP draft would = likely become "always use IKE over TCP" in a product (my company's clients = that had IKE-over-TCP did exactly that), whereas fragmentation is more like= ly to become "use fragmentation if the the regular UDP did not get an answe= r". So: "I would prefer the WG to stop working on IKEv2 over TCP and instead work o= n standardizing IKEv2 fragmentation" However, I would prefer that we clear up the situation with Microsoft's IPR= before making such a change to our charter. Yoav From paul@nohats.ca Thu Mar 14 06:20:29 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CBD21F8FE5 for ; Thu, 14 Mar 2013 06:20:29 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1l9ykXw-zAo for ; Thu, 14 Mar 2013 06:20:28 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 732A621F8F53 for ; Thu, 14 Mar 2013 06:20:28 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZRVsN4hhwz3dc; Thu, 14 Mar 2013 09:20:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id UK0MRE1CNMFb; Thu, 14 Mar 2013 09:20:23 -0400 (EDT) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 14 Mar 2013 09:20:23 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 2172E8085F; Thu, 14 Mar 2013 09:20:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 12089804F3; Thu, 14 Mar 2013 09:20:23 -0400 (EDT) Date: Thu, 14 Mar 2013 09:20:23 -0400 (EDT) From: Paul Wouters To: Yoav Nir In-Reply-To: Message-ID: References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Informal poll on IKEv2 { over TCP | fragmentation } X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 13:20:29 -0000 On Thu, 14 Mar 2013, Yoav Nir wrote: > "I would prefer the WG to stop working on IKEv2 over TCP and instead work on standardizing IKEv2 fragmentation" +1 > However, I would prefer that we clear up the situation with Microsoft's IPR before making such a change to our charter. Less worried about the IPR claim. Paul From svanru@gmail.com Thu Mar 14 06:38:51 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0290821F8CF7 for ; Thu, 14 Mar 2013 06:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.303 X-Spam-Level: **** X-Spam-Status: No, score=4.303 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TdA2dvUnyTp for ; Thu, 14 Mar 2013 06:38:50 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id C9ECE21F8CE2 for ; Thu, 14 Mar 2013 06:38:49 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id fs13so2466467lab.36 for ; Thu, 14 Mar 2013 06:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:cc:references:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:x-mimeole; bh=5gTJWPIJ/lmtfsrMmiahCxSaaEhAGv/1SYowb4ApJvY=; b=Nl6+g9FBEYNtsG+OL4Ev58kPHv59uLNgqjhg6yx5Bt7uMbazAC43hPlZ9FxQn1U6pD XinWSPI5PdfswDhPaXbQAneKIoQSLA4F3s+QZbQ6mXutMMz2K//gkpu9QAJFdloDYqnl 8rCe34JllrZfydrlqsaYqImjx34GS+Vg3/td9dmTmUZRkm5+P83Z5svtSK5bdApQRCyq wZMu99YdHr15TAVCsu5TeKnHT6Y5E1onfMASK/mcBH2DZa3fqgjDSIaWAmo2aQMNvVm/ gMeTR39A+pzOYD1IL79FgOtcHxT5mt49Q9cNKjwEbv8vw3Eza+on3SoVOpfkiYd/0635 CZFA== X-Received: by 10.152.144.202 with SMTP id so10mr2286392lab.9.1363268316597; Thu, 14 Mar 2013 06:38:36 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPS id go12sm1206639lab.3.2013.03.14.06.38.34 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 14 Mar 2013 06:38:35 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Yoav Nir" References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> <51408287.7080207@gmail.com> <3028CF35E60A40068CE70EB7BB0BDEF1@buildpc> Date: Thu, 14 Mar 2013 17:38:48 +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 Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 13:38:51 -0000 Hi Yoav. > > I agree that term "authenticated" is a bit misleading here. > > The better term would be "integrity protected". > > In our proposal receiver can be absolutely sure that > > each fragment comes from the very peer he/she exchanged > > DH exponents and calculated shared secret with. > > > > All fragments which ICV cannot be verified are discarded > > and don't prevent communication with real peer in any way. > > So in order to get the responder to spend memory resources on storing the > fragment, the initiator needs to expand > CPU resources on completing the D-H calculation, and calculating > integrity protection on the fragment. Makes sense. Sorry, did you read the draft? There is no DH calculating per fragment. DH is calculated once in IKE_SA_INIT as in ordinary IKE SA establishment (note, that unprotected messages, including IKE_SA_INIT and IKE_SA_RESUME cannot be fragmented). And you spent absolutetly the same amount of CPU power to calculate/verify ICV on fragments as you would spend it on non-fragmented message (probably a little bit more, as total length of all fragments of one message could be a bit more than the length of original message due to padding, IKE header and so on, but the usual difference is few percents). Let me emphasize again. 1. In our proposal sender and receiver spend roughly the same amount of CPU power as they would spend on protecting/verifying non-fragmented message. 2. In our proposal sender and receiver spend roughly the same amount of CPU power as they would spend on protecting/verifying fragmented message in Cisco/MS solution. 3. In our proposal sender needs to encrypt/protect one message twice only once per SA establishments and only if he/she tries first to send unfragmented message and after some retransmits decides to resend it fragmented. This is avoidable if sender always sends large messages fragmented. 4. Comparing to Cisco/MS solution our proposal allows receiver to verify integrity of individual fragment, so forged fragments will not consume receiver's memory and could not prevent receiver from getting valid fragments. > What do you get when you put together the fragments? a decrypted IKE > message? Just the list of payloads? After you decrypt and verify content of Encrypted Fragment Payload of all fragments, get rid of now unnecessary headers and put all together, you get a decrypted IKE message. > Yoav= Regards, Valery. From svanru@gmail.com Thu Mar 14 06:42:00 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C226311E812A for ; Thu, 14 Mar 2013 06:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.303 X-Spam-Level: **** X-Spam-Status: No, score=4.303 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id me0aaRJx9fyu for ; Thu, 14 Mar 2013 06:42:00 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id DE00C11E8129 for ; Thu, 14 Mar 2013 06:41:59 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id fs12so2432410lab.39 for ; Thu, 14 Mar 2013 06:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=o5V+ZXJzlUzSGFr2Wy5GFTXEnqsaeTTuwhCGmVDeTqY=; b=JBacIEJVA1YuJrsurv0+aVuOlj+XVo1Hpw4VHL2pqQDcBC9FlUvkTBSUZvS5OWj72l 8R8GgX6MoyXZafbpzVlUdSwp2xeprS8/w6m+1CbQRIQ9/8bTs6+YLoACBOaYC9ijOlkS R0Y7z/jg7upmxKvx1k/kN6APTJ1bObm1W4WLR7ZrHc8riD976heKmEel4Q7T+wOATGa4 8bPMwGlUeZ8bvneD+dQBOVTuQkvvDHIjZPLKHqYOzulMeNG0PY0Z8M4aRRABWcIU63Hm nMeYvKtmNpbFZR9llHINBwWWtFYeQkaknN8yZ+bpHUcr+3oy+NCYkUfG2+LHqLVtDVNb 4Xzw== X-Received: by 10.152.110.167 with SMTP id ib7mr2263159lab.22.1363268518792; Thu, 14 Mar 2013 06:41:58 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPS id m6sm841679lbm.10.2013.03.14.06.41.56 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 14 Mar 2013 06:41:57 -0700 (PDT) Message-ID: <720945E8E0AB4F3185144CF28437ECEE@buildpc> From: "Valery Smyslov" To: "Paul Hoffman" , "IPsecme WG" References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> Date: Thu, 14 Mar 2013 17:42:10 +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 Subject: Re: [IPsec] Informal poll on IKEv2 { over TCP | fragmentation } X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 13:42:00 -0000 > - I would prefer the WG to stop working on IKEv2 over TCP and instead work > on standardizing IKEv2 fragmentation I vote for this option. Valery. From ynir@checkpoint.com Thu Mar 14 07:10:49 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635F711E811F for ; Thu, 14 Mar 2013 07:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.224 X-Spam-Level: X-Spam-Status: No, score=-9.224 tagged_above=-999 required=5 tests=[AWL=1.375, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBhf9j2LUFqO for ; Thu, 14 Mar 2013 07:10:48 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 03D7B21F8CA2 for ; Thu, 14 Mar 2013 07:10:47 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2EEAfEs029651; Thu, 14 Mar 2013 16:10:41 +0200 X-CheckPoint: {5141D985-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 16:10:41 +0200 From: Yoav Nir To: Valery Smyslov Thread-Topic: [IPsec] IKE fragmentation Thread-Index: AQHOH/P+dHmEPMd7P0SMbddmnpEj3pikJ5oAgAEK/gb//+digA== Date: Thu, 14 Mar 2013 14:10:40 +0000 Message-ID: References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> <51408287.7080207@gmail.com> <3028CF35E60A40068CE70EB7BB0BDEF1@buildpc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.209] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-ID: <19BF7912AC64F249AAB1069FFE17E8D0@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Tero Kivinen Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:10:49 -0000 On Mar 14, 2013, at 9:38 AM, Valery Smyslov wrote: > Hi Yoav. >=20 >> > I agree that term "authenticated" is a bit misleading here. >> > The better term would be "integrity protected". >> > In our proposal receiver can be absolutely sure that >> > each fragment comes from the very peer he/she exchanged >> > DH exponents and calculated shared secret with. >> > >> > All fragments which ICV cannot be verified are discarded >> > and don't prevent communication with real peer in any way. >>=20 >> So in order to get the responder to spend memory resources on storing th= e fragment, the initiator needs to expand >> CPU resources on completing the D-H calculation, and calculating integr= ity protection on the fragment. Makes sense. >=20 > Sorry, did you read the draft? Yes. > There is no DH calculating per fragment. DH is calculated once in IKE_SA_= INIT > as in ordinary IKE SA establishment (note, that unprotected messages, inc= luding IKE_SA_INIT > and IKE_SA_RESUME cannot be fragmented). If we do IKEv2 fragments the way everyone does IKEv1 fragments, the initiat= or can send multiple fragments that don't assemble to a protected packet, c= ausing the responder to allocate memory to store these fragments (at least = for a short while). Doing this does not require completing the D-H calculat= ion, and does not require running either an encryption or MAC function. What your draft does, is force the initiator to protect each fragment. To p= rotect a fragment in a way that will cause the responder to store it, requi= res running the MAC function, and that in turn requires generating the keys= (running the PRF), which in turn requires completing the D-H calculation. = If the initiator fails to do any of these things, the fragment will be imme= diately rejected at the responder. Of course, the D-H calculation is not pe= r-fragment, and I did not claim that this was the case. > And you spent absolutetly the same amount of CPU power to calculate/verif= y ICV on > fragments as you would spend it on non-fragmented message You spend the same amount only if you require that your ICV verify. This is= not needed for creating DoS on the way fragmentation is done in IKEv1. > (probably a little bit more, as total length of all fragments of one mess= age could > be a bit more than the length of original message due to padding, IKE hea= der and so on, > but the usual difference is few percents). Measurably more, because MAC functions have an initialization part, so runn= ing it on a single packet by parts incurs the per-run overhead multiple tim= es. See the differences in the throughput of HMAC based on buffer size (obt= ained by running "opnessl speed": type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 byt= es hmac(md5) 17801.04k 53527.61k 132966.20k 210528.97k 253873.= 49k So if the packet is 8000 bytes, and you divided it into 1024 fragments, you= would incur a slightly more than 20% penalty. >=20 > Let me emphasize again. > 1. In our proposal sender and receiver spend roughly the same amount of C= PU power > as they would spend on protecting/verifying non-fragmented message. > 2. In our proposal sender and receiver spend roughly the same amount of C= PU power > as they would spend on protecting/verifying fragmented message in Cisco= /MS solution. > 3. In our proposal sender needs to encrypt/protect one message twice only= once > per SA establishments and only if he/she tries first to send unfragment= ed > message and after some retransmits decides to resend it fragmented. > This is avoidable if sender always sends large messages fragmented. > 4. Comparing to Cisco/MS solution our proposal allows receiver to > verify integrity of individual fragment, so forged fragments will not > consume receiver's memory and could not prevent receiver > from getting valid fragments. >=20 >> What do you get when you put together the fragments? a decrypted IKE mes= sage? Just the list of payloads? >=20 > After you decrypt and verify content of Encrypted Fragment Payload of all= fragments, > get rid of now unnecessary headers and put all together, you get a decryp= ted IKE message. Good. Yoav From paul@cypherpunks.ca Thu Mar 14 07:28:07 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194CE21F90B5 for ; Thu, 14 Mar 2013 07:28:07 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+bVfEy7SCkd for ; Thu, 14 Mar 2013 07:28:04 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5107821F90AF for ; Thu, 14 Mar 2013 07:28:01 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZRXMJ6pDZz3sq; Thu, 14 Mar 2013 10:27:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id PlyqWAtU4sX9; Thu, 14 Mar 2013 10:27:53 -0400 (EDT) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 14 Mar 2013 10:27:53 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id EC09480860; Thu, 14 Mar 2013 10:27:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D8D7E8085F; Thu, 14 Mar 2013 10:27:52 -0400 (EDT) Date: Thu, 14 Mar 2013 10:27:52 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Yoav Nir In-Reply-To: Message-ID: References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> <51408287.7080207@gmail.com> <3028CF35E60A40068CE70EB7BB0BDEF1@buildpc> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "" , Valery Smyslov , Tero Kivinen Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:28:07 -0000 On Thu, 14 Mar 2013, Yoav Nir wrote: > Measurably more, because MAC functions have an initialization part, so running it on a single packet by parts incurs the per-run overhead multiple times. See the differences in the throughput of HMAC based on buffer size (obtained by running "opnessl speed": > > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > hmac(md5) 17801.04k 53527.61k 132966.20k 210528.97k 253873.49k > > So if the packet is 8000 bytes, and you divided it into 1024 fragments, you would incur a slightly more than 20% penalty. I don't understand this part? Legitimate fragments won't have a count higher then about 10. Current implementations I've seen cap at 16 fragments. If you receive a fragment number higher then that, you discard the whole thing. You could even wait with decrypting until you got all fragments. I don't see much value in authenticating each fragment. Possibly they would come in faster then you can decrypt each fragment anyway, so you need to store them regardless, especially in a DoS where the initiator does not perform real encryption for sending fragments. I would likely implement it to receive all fragments, then run decryption on all its parts. Furthermore, since we have the cookies/SPI, it is also pretty easy to ignore bogus fragments, and to require the 6 message echange when receiving a first-packet for a new exchange when under high load, so IKE spoofing won't cause us that much of a higher load. So I'm not too worried about the DOS, and I'm leaning towards a similar model to the currently deployed method for IKEv1. Possibly dropping the useless "fragment id" (not fragment number) Paul From kivinen@iki.fi Thu Mar 14 07:31:45 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073FA11E8192 for ; Thu, 14 Mar 2013 07:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9voWl0iEO6fx for ; Thu, 14 Mar 2013 07:31:43 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC15B11E8188 for ; Thu, 14 Mar 2013 07:31:21 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r2EETiDF014461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Mar 2013 16:29:44 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r2EEThQn000832; Thu, 14 Mar 2013 16:29:43 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20801.57047.617753.249763@fireball.kivinen.iki.fi> Date: Thu, 14 Mar 2013 16:29:43 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> <51408287.7080207@gmail.com> <3028CF35E60A40068CE70EB7BB0BDEF1@buildpc> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 18 min X-Total-Time: 17 min Cc: "" , Valery Smyslov Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:31:48 -0000 Yoav Nir writes: > > There is no DH calculating per fragment. DH is calculated once in > > IKE_SA_INIT as in ordinary IKE SA establishment (note, that > > unprotected messages, including IKE_SA_INIT and IKE_SA_RESUME > > cannot be fragmented). > > If we do IKEv2 fragments the way everyone does IKEv1 fragments, the > initiator can send multiple fragments that don't assemble to a > protected packet, causing the responder to allocate memory to store > these fragments (at least for a short while). Doing this does not > require completing the D-H calculation, and does not require running > either an encryption or MAC function. I would assume all implementations start doing Diffie-Hellman even before than they even see the first fragment. I.e. when the responder sends it IKE_SA_INIT reply back it will also start the Diffie-Hellman calculation on the background so it might be ready when it gets next packet from the initiator. The initiator must do the Diffie-Hellman before it can send first IKE_AUTH packet anyways. When responder gets IKE_AUTH packet from the initiator, then they will start Diffie-Hellman calculation if they have not yet done it previously. > What your draft does, is force the initiator to protect each > fragment. To protect a fragment in a way that will cause the > responder to store it, requires running the MAC function, and that > in turn requires generating the keys (running the PRF), which in > turn requires completing the D-H calculation. If the initiator fails > to do any of these things, the fragment will be immediately rejected > at the responder. Of course, the D-H calculation is not > per-fragment, and I did not claim that this was the case. Initiator must do Diffie-Hellman anyways before it can send IKE_AUTH. Responder must do Diffie-Hellman anyways before it can process incoming IKE_AUTH. And as the fragments are not acknowledged separately the responder implementation can store all the encrypted and authenticated fragments wihtout checking and when it all of them, it can do Diffie-Hellman and decrypt + authentication to all of them, just like in the IKEv1 fragment version. So there is no big difference there. The big differences is that smart implementation can check fragments as they come in, thus it can immediately reject bogus fragments, and only store and try reassembly on the valid fragments. As earlier explained not doing that allows very wasy DoS attack, which allows IKEv2 to finish by just sending very few packets, i.e. you send one corrupted fragment to the packet and if you do that before responder gets the correct fragment, the responder stores it for reassembly and after it reassembles the packet it will only then notice that the packet is corrupted, and then it needs to throw the whole packet away. It cannot know which of the fragment is corrupted. This means the initiator needs to retransmit whole packet, i.e. all fragments of it, and attacker can do this again. I think doing authentication per fragment is MUCH better method of doing the fragmentation. > Measurably more, because MAC functions have an initialization part, > so running it on a single packet by parts incurs the per-run > overhead multiple times. See the differences in the throughput of > HMAC based on buffer size (obtained by running "opnessl speed": We are talking about IKE_AUTH here, and we will do the Diffie-Hellman, and most likely also public key signature verification and generation here (fragmentation is most likely only needed if we do have certificates inside the packet, shared secret authentication should work without fragmentation). > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > hmac(md5) 17801.04k 53527.61k 132966.20k 210528.97k 253873.49k > > So if the packet is 8000 bytes, and you divided it into 1024 > fragments, you would incur a slightly more than 20% penalty. It's actually more useful to compare the speeds from the 1024 bytes down to 512 bytes and then add Diffie-Hellman over group 14 and RSA signature verification + generation over 2048 bit key and check the time difference there. I would expect it to be almost unnoticeable. -- kivinen@iki.fi From ynir@checkpoint.com Thu Mar 14 07:38:29 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D0321F8DF9 for ; Thu, 14 Mar 2013 07:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oa+GyVpmpoeY for ; Thu, 14 Mar 2013 07:38:13 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id F1F0311E811F for ; Thu, 14 Mar 2013 07:38:09 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2EEc07X004865; Thu, 14 Mar 2013 16:38:00 +0200 X-CheckPoint: {5141DFEB-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 16:38:00 +0200 From: Yoav Nir To: Paul Wouters Thread-Topic: [IPsec] IKE fragmentation Thread-Index: AQHOH/P+dHmEPMd7P0SMbddmnpEj3pikJ5oAgAEK/gb//+digIAABM8AgAAC0gA= Date: Thu, 14 Mar 2013 14:37:58 +0000 Message-ID: <0D1C9992-4419-4182-85DC-E38E6B3E292A@checkpoint.com> References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> <51408287.7080207@gmail.com> <3028CF35E60A40068CE70EB7BB0BDEF1@buildpc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.209] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Valery Smyslov , Tero Kivinen Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:38:29 -0000 On Mar 14, 2013, at 10:27 AM, Paul Wouters wrote: > On Thu, 14 Mar 2013, Yoav Nir wrote: >=20 >> Measurably more, because MAC functions have an initialization part, so r= unning it on a single packet by parts incurs the per-run overhead multiple = times. See the differences in the throughput of HMAC based on buffer size (= obtained by running "opnessl speed": >>=20 >> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 = bytes >> hmac(md5) 17801.04k 53527.61k 132966.20k 210528.97k 2538= 73.49k >>=20 >> So if the packet is 8000 bytes, and you divided it into 1024 fragments, = you would incur a slightly more than 20% penalty. >=20 > I don't understand this part? Legitimate fragments won't have a > count higher then about 10. Current implementations I've seen cap at > 16 fragments. If you receive a fragment number higher then that, you > discard the whole thing. You could even wait with decrypting until you > got all fragments. True for the way things are done in IKEv1, but Valery's draft has you at le= ast calculating the MAC for each fragment before storing. MAC-ing each frag= ment is 20% more expensive (for a 8000-byte message) than MAC-ing the whole= thing. Not that it matters - it's all in the noise considering that there'= s also a D-H operation taking place. > I don't see much value in authenticating each fragment. Possibly they > would come in faster then you can decrypt each fragment anyway, so you > need to store them regardless, especially in a DoS where the initiator > does not perform real encryption for sending fragments. >=20 > I would likely implement it to receive all fragments, then run > decryption on all its parts. In that case you don't get the DoS protection offered by this draft. > Furthermore, since we have the cookies/SPI, it is also pretty easy to > ignore bogus fragments, and to require the 6 message echange when > receiving a first-packet for a new exchange when under high load, so > IKE spoofing won't cause us that much of a higher load. >=20 > So I'm not too worried about the DOS, and I'm leaning towards a similar > model to the currently deployed method for IKEv1. Possibly dropping > the useless "fragment id" (not fragment number) It's a tradeoff of memory vs CPU. I'm not sure which is more constrained. Yoav From ynir@checkpoint.com Thu Mar 14 07:49:58 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C294B11E8150 for ; Thu, 14 Mar 2013 07:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.141 X-Spam-Level: X-Spam-Status: No, score=-10.141 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VzI-6BD5asS for ; Thu, 14 Mar 2013 07:49:58 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3516B11E8146 for ; Thu, 14 Mar 2013 07:49:56 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2EEns6j009086; Thu, 14 Mar 2013 16:49:54 +0200 X-CheckPoint: {5141E2B5-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 16:49:54 +0200 From: Yoav Nir To: Tero Kivinen Thread-Topic: [IPsec] IKE fragmentation Thread-Index: AQHOH/P+dHmEPMd7P0SMbddmnpEj3pikJ5oAgAEK/gb//+digIAABVOAgAAFoQA= Date: Thu, 14 Mar 2013 14:49:53 +0000 Message-ID: References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> <51408287.7080207@gmail.com> <3028CF35E60A40068CE70EB7BB0BDEF1@buildpc> <20801.57047.617753.249763@fireball.kivinen.iki.fi> In-Reply-To: <20801.57047.617753.249763@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.209] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Valery Smyslov Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:49:58 -0000 On Mar 14, 2013, at 10:29 AM, Tero Kivinen wrote: > Yoav Nir writes: >>> There is no DH calculating per fragment. DH is calculated once in >>> IKE_SA_INIT as in ordinary IKE SA establishment (note, that >>> unprotected messages, including IKE_SA_INIT and IKE_SA_RESUME >>> cannot be fragmented). >>=20 >> If we do IKEv2 fragments the way everyone does IKEv1 fragments, the >> initiator can send multiple fragments that don't assemble to a >> protected packet, causing the responder to allocate memory to store >> these fragments (at least for a short while). Doing this does not >> require completing the D-H calculation, and does not require running >> either an encryption or MAC function.=20 >=20 > I would assume all implementations start doing Diffie-Hellman even > before than they even see the first fragment. I.e. when the responder > sends it IKE_SA_INIT reply back it will also start the Diffie-Hellman > calculation on the background so it might be ready when it gets next > packet from the initiator. The initiator must do the Diffie-Hellman > before it can send first IKE_AUTH packet anyways. >=20 > When responder gets IKE_AUTH packet from the initiator, then they will > start Diffie-Hellman calculation if they have not yet done it > previously.=20 My implementation does that. We only calculate the shared key when we need = it - when the IKE_AUTH request arrives. >> What your draft does, is force the initiator to protect each >> fragment. To protect a fragment in a way that will cause the >> responder to store it, requires running the MAC function, and that >> in turn requires generating the keys (running the PRF), which in >> turn requires completing the D-H calculation. If the initiator fails >> to do any of these things, the fragment will be immediately rejected >> at the responder. Of course, the D-H calculation is not >> per-fragment, and I did not claim that this was the case. >=20 > Initiator must do Diffie-Hellman anyways before it can send IKE_AUTH. True for a legitimate Initiator. At attacker can send fake fragments, and t= he responder has the option of expanding CPU resources for verifying the IC= V, or expanding the memory resources for storing them for a while. >> Measurably more, because MAC functions have an initialization part, >> so running it on a single packet by parts incurs the per-run >> overhead multiple times. See the differences in the throughput of >> HMAC based on buffer size (obtained by running "opnessl speed": >=20 > We are talking about IKE_AUTH here, and we will do the Diffie-Hellman, > and most likely also public key signature verification and generation > here (fragmentation is most likely only needed if we do have > certificates inside the packet, shared secret authentication should > work without fragmentation).=20 >=20 >> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 byte= s >> hmac(md5) 17801.04k 53527.61k 132966.20k 210528.97k 253873.4= 9k >>=20 >> So if the packet is 8000 bytes, and you divided it into 1024 >> fragments, you would incur a slightly more than 20% penalty. >=20 > It's actually more useful to compare the speeds from the 1024 bytes > down to 512 bytes and then add Diffie-Hellman over group 14 and RSA > signature verification + generation over 2048 bit key and check the > time difference there. I would expect it to be almost unnoticeable.=20 I agree it's in the noise. From svanru@gmail.com Thu Mar 14 07:51:17 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF70711E81D0 for ; Thu, 14 Mar 2013 07:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.003 X-Spam-Level: *** X-Spam-Status: No, score=3.003 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmTCI0zOdbe1 for ; Thu, 14 Mar 2013 07:51:16 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3014411E819E for ; Thu, 14 Mar 2013 07:51:15 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id eb20so2585568lab.17 for ; Thu, 14 Mar 2013 07:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:cc:references:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:x-mimeole; bh=ztS6cUSjinRkn8lP+zFAv4i7T1CvF94ukVGhCXdvC6Q=; b=gFxU8YbCEKhs2HURJKeQpxszN9pz8er/JXwzE2qQh1fO1s4iDw56fIR/PzypuVu5HP 2847Ke4EEqRtg+M59R/e6SC72wrcOi5V6A3PH534vkOqxyR9gyr8unMZfFTGW5+X3qCj sdmikoER8JYJC4lmEsYMgYvQtJx6a8sWWCVyskMZjG2XgeKT9CSTWNNvOxqS8dKlC2m/ XdhDwa9knh6PXIh4RoPOPmIz5FyWokL8T980OVUYMJ0GMEYl29tABupRrQD9y2dckMZk i29HWJEegWufwcd3e2u8SA+OAzeRzRw0PM9Qiple6N67Cg790gzTbZ2LH9LY0iGehNsB Q91g== X-Received: by 10.152.125.239 with SMTP id mt15mr2477731lab.26.1363272674104; Thu, 14 Mar 2013 07:51:14 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPS id o11sm915399lbu.6.2013.03.14.07.51.12 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 14 Mar 2013 07:51:13 -0700 (PDT) Message-ID: <8499A22E140C4EE3AAD3D79C4E304094@buildpc> From: "Valery Smyslov" To: "Yoav Nir" References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> <51408287.7080207@gmail.com> <3028CF35E60A40068CE70EB7BB0BDEF1@buildpc> Date: Thu, 14 Mar 2013 18:51:27 +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 Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:51:17 -0000 > > There is no DH calculating per fragment. DH is calculated once in > > IKE_SA_INIT > > as in ordinary IKE SA establishment (note, that unprotected messages, > > including IKE_SA_INIT > > and IKE_SA_RESUME cannot be fragmented). > > If we do IKEv2 fragments the way everyone does IKEv1 fragments, the > initiator can send multiple fragments that don't assemble to a > protected packet, causing the responder to allocate memory to store these > fragments (at least for a short while). Doing this does not > require completing the D-H calculation, and does not require running > either an encryption or MAC function. Yes, in our solution only protected messages could be fragmented. This is its limitation. But in IKEv2 all messages except for IKE_SA_INIT, IKE_SA_RESUME and some informational must be protected. > What your draft does, is force the initiator to protect each fragment. To > protect a fragment in a way that will cause the responder > to store it, requires running the MAC function, and that in turn requires > generating the keys (running the PRF), which in turn requires > completing the D-H calculation. If the initiator fails to do any of these > things, the fragment will be immediately rejected at the responder. Yes, but initiator needs to do it in any case. You cannot send protected message (fragmented or not) without calculating DH, SKEYSEED etc. > Of course, the D-H calculation is not per-fragment, and I did not claim > that this was the case. Sorry I didn't quite catch you. > > And you spent absolutetly the same amount of CPU power to > > calculate/verify ICV on > > fragments as you would spend it on non-fragmented message > > You spend the same amount only if you require that your ICV verify. This > is not needed for creating DoS on the way fragmentation > is done in IKEv1. ICV must be verified in any case - fragmented or non-fragmented. > > (probably a little bit more, as total length of all fragments of one > > message could > > be a bit more than the length of original message due to padding, IKE > > header and so on, > > but the usual difference is few percents). > > Measurably more, because MAC functions have an initialization part, so > running it on a single packet by parts incurs the per-run > overhead multiple times. See the differences in the throughput of HMAC > based on buffer size (obtained by running "opnessl speed": > > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 > bytes > hmac(md5) 17801.04k 53527.61k 132966.20k 210528.97k > 253873.49k > > So if the packet is 8000 bytes, and you divided it into 1024 fragments, > you would incur a slightly more than 20% penalty. Yes, as I've said there is some penalty. It may differ depending on algorithm and implementation. I don't see a big problem here, as ICV computation must be fast anyway. Valery. From paul@cypherpunks.ca Thu Mar 14 07:52:03 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7949411E819E for ; Thu, 14 Mar 2013 07:52:03 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OU9j6Nlakb4b for ; Thu, 14 Mar 2013 07:52:03 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id A92CA11E8158 for ; Thu, 14 Mar 2013 07:52:02 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZRXv433Whz3sq; Thu, 14 Mar 2013 10:52:00 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 1aQQfWFfzbWr; Thu, 14 Mar 2013 10:51:59 -0400 (EDT) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 14 Mar 2013 10:51:58 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 935F080860; Thu, 14 Mar 2013 10:51:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 882D48085F; Thu, 14 Mar 2013 10:51:58 -0400 (EDT) Date: Thu, 14 Mar 2013 10:51:58 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Tero Kivinen In-Reply-To: <20801.57047.617753.249763@fireball.kivinen.iki.fi> Message-ID: References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> <51408287.7080207@gmail.com> <3028CF35E60A40068CE70EB7BB0BDEF1@buildpc> <20801.57047.617753.249763@fireball.kivinen.iki.fi> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "" , Valery Smyslov , Yoav Nir Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:52:03 -0000 On Thu, 14 Mar 2013, Tero Kivinen wrote: > As earlier explained not doing that allows very wasy DoS attack, which > allows IKEv2 to finish by just sending very few packets, i.e. you send > one corrupted fragment to the packet and if you do that before > responder gets the correct fragment, the responder stores it for > reassembly and after it reassembles the packet it will only then > notice that the packet is corrupted, and then it needs to throw the > whole packet away. It cannot know which of the fragment is corrupted. > This means the initiator needs to retransmit whole packet, i.e. all > fragments of it, and attacker can do this again. Note that requires an observer that can see your cookies/spi. Which would mean a local attacker, whom could just as easilly send you nonsense forged from the remote endpoint - as they are guaranteed to answer faster. You'd be decrypting thousands of packets to find the needle in the haystack. I wonder what the chances then are that you don't end up dropping teh valid fragment. If the attacker is not local, they need to be in your path to know the spi/cookies, and they can just filter out the valid fragments. But I see your point, it does raise the bar a little bit. Although I'm not convinced it's worth it. Paul From svanru@gmail.com Thu Mar 14 08:08:57 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925EB11E8271 for ; Thu, 14 Mar 2013 08:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.57 X-Spam-Level: ** X-Spam-Status: No, score=2.57 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blFqtj+2CcrM for ; Thu, 14 Mar 2013 08:08:56 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id DE58111E8262 for ; Thu, 14 Mar 2013 08:08:37 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id fs13so2545612lab.8 for ; Thu, 14 Mar 2013 08:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:cc:references:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:x-mimeole; bh=nDC1R7Zl+3Sa0gSSSyoWvDPr7nX/byQDzjC1UdMFnXg=; b=e3D88hoKnF57vzy4H3FvtuyTirTPPOLjYs30DHS6GkOoRaxReWWau8AXndwJGyQw6V +rtVvytCQTm+dTkfhOi2z2t8r3fVg9vemz1ytoum77g7gElIezbk9jsa4MG72FZi4VI6 II4Ynvay4wOtz3KYi5Voidoq8b5wvZaZQqsBOd66cc6BN06BlcpWc0mruUovSogTXPnC dC9QHurSNhmk/qQICyu2zAE9W6cqKv84mCphLaDTbdIdJ9PURjjHroGbA62+ruBiAMLl pOg+MzeusntrvfNr8OGIULUMVeJZff/ST1ZiozI0Scss6PFOxVeXiZwpgs35QWBXWU+2 l9hg== X-Received: by 10.152.105.17 with SMTP id gi17mr2457252lab.46.1363273714272; Thu, 14 Mar 2013 08:08:34 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPS id c10sm928089lbu.11.2013.03.14.08.08.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 14 Mar 2013 08:08:33 -0700 (PDT) Message-ID: <37EA3A0F84914E7FAB43CF50ABA9F780@buildpc> From: "Valery Smyslov" To: "Yoav Nir" , "Tero Kivinen" References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> <51408287.7080207@gmail.com> <3028CF35E60A40068CE70EB7BB0BDEF1@buildpc> <20801.57047.617753.249763@fireball.kivinen.iki.fi> Date: Thu, 14 Mar 2013 19:08:47 +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 Cc: ipsec@ietf.org Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 15:08:58 -0000 > >> What your draft does, is force the initiator to protect each > >> fragment. To protect a fragment in a way that will cause the > >> responder to store it, requires running the MAC function, and that > >> in turn requires generating the keys (running the PRF), which in > >> turn requires completing the D-H calculation. If the initiator fails > >> to do any of these things, the fragment will be immediately rejected > >> at the responder. Of course, the D-H calculation is not > >> per-fragment, and I did not claim that this was the case. > > > > Initiator must do Diffie-Hellman anyways before it can send IKE_AUTH. > > True for a legitimate Initiator. At attacker can send fake fragments, and > the responder has the option of expanding > CPU resources for verifying the ICV, or expanding the memory resources for > storing them for a while. There is no difference comparing with usual, non-fragmented IKE_AUTH message - responder still can be forced by attacker to complete DH, calculate keys and try to verify forged message. And fragmentation doesn't make it worse. And even with unprotected fragments it is not a big deal for attacker to send you a set of fragments that you will successfully reassemble to a good-looking message and then you again will have to complete DH, calculate keys and try to verify that garbage. No difference. From kivinen@iki.fi Thu Mar 14 08:09:59 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111C911E827C for ; Thu, 14 Mar 2013 08:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zv-Q5UFNL7Db for ; Thu, 14 Mar 2013 08:09:50 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id D774511E823E for ; Thu, 14 Mar 2013 08:09:45 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r2EF8B9G015386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Mar 2013 17:08:11 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r2EF8B1D018616; Thu, 14 Mar 2013 17:08:11 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20801.59355.157237.370109@fireball.kivinen.iki.fi> Date: Thu, 14 Mar 2013 17:08:11 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> <51408287.7080207@gmail.com> <3028CF35E60A40068CE70EB7BB0BDEF1@buildpc> <20801.57047.617753.249763@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: "" , Valery Smyslov , Yoav Nir Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 15:09:59 -0000 Paul Wouters writes: > Note that requires an observer that can see your cookies/spi. Yes. > Which would > mean a local attacker, whom could just as easilly send you nonsense > forged from the remote endpoint - as they are guaranteed to answer > faster. You'd be decrypting thousands of packets to find the needle in > the haystack. I wonder what the chances then are that you don't end up > dropping teh valid fragment. My PC has more than enough CPU power to verify MAC on the packets coming in over the wireless link. On the other hand if attacker fills the wireless link with junk packets, it is very easy to find him. If attacker just sends on random packet every 2 seconds, it is much harder to pinpoint who and where he is. The idea of DoS protection is to make the attack more expensive for the attacker, and also make detecting him easier. Adding MAC to fragments does both. -- kivinen@iki.fi From mcgrew@cisco.com Thu Mar 14 12:41:33 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A9A11E81F4 for ; Thu, 14 Mar 2013 12:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I44gyDZ43UVK for ; Thu, 14 Mar 2013 12:41:32 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF6B11E8166 for ; Thu, 14 Mar 2013 12:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1188; q=dns/txt; s=iport; t=1363290092; x=1364499692; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=i+c8pbya40rZyOoA1R3g4tHW5r6WxRMpidFUEdYNq9s=; b=Yd4kLteOFZr9RMR3hI2ng0zZ1MwLyXZDiKsFwgzPyutazFLHdeHHvHgA cUZylnD3HNNO3u/6WSM8RJzyZTMkjlg0m0XABh73rzsSvgwmzfyRbH0eO axCxuAvNyT4rCxSE3saIFebp7mLNypXbCxtf0bkw7HhQPaexMdB4qp5T0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABonQlGtJV2a/2dsb2JhbABDxQKBZRZ0gi0BBAEBATc0HQEIIhQ3CyUCBAESCIgMDMFhBI5lOIJfYQOnWoMKgig X-IronPort-AV: E=Sophos;i="4.84,846,1355097600"; d="scan'208";a="187632846" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 14 Mar 2013 19:41:31 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2EJfUBi017438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 19:41:30 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 14:41:30 -0500 From: "David McGrew (mcgrew)" To: "Frankel, Sheila E." , IPsecme WG Thread-Topic: [IPsec] Updated ESP/AH algorithm I-D Thread-Index: AQHOHypcm7BoNqYzAkOdJwnzwDYHfJilqkMA Date: Thu, 14 Mar 2013 19:41:29 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183EA09B@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Updated ESP/AH algorithm I-D X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:41:33 -0000 Hi Sheila, Thanks for pointing this out. I agree that the draft needs to be changed to align with the ESP RFC. David On 3/12/13 10:01 AM, "Frankel, Sheila E." wrote: >Hi David and Wajdi, > >Your updated ESP/AH algorithm doc looks great, and is very much needed. I >just have one comment. You speak of the 2 services provided by ESP and AH >as confidentiality and "data origin authentication." As I'm sure you >know, authentication is used in different ways by different communities. >I believe that in most of the IPsec docs the 1st service is referred to >interchangeably as encryption and confidentiality; the 2nd service is >interchangeably referred to as authentication and integrity protection. >However, in RFC 4303 (ESP) it states: "Data origin authentication and >connectionless integrity are joint services, hereafter referred to >jointly as "integrity"." In your doc, the integrity-protection aspect is >not mentioned at all, and I believe that is a critical oversight. > >Sheila Frankel >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From Paul_Koning@Dell.com Thu Mar 14 12:42:40 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513AC11E8227 for ; Thu, 14 Mar 2013 12:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azxuKps+GKKi for ; Thu, 14 Mar 2013 12:42:39 -0700 (PDT) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) by ietfa.amsl.com (Postfix) with ESMTP id B24C211E821C for ; Thu, 14 Mar 2013 12:42:39 -0700 (PDT) X-LoopCount0: from 10.170.28.41 X-IronPort-AV: E=Sophos;i="4.84,846,1355119200"; d="scan'208";a="95811992" From: To: Thread-Topic: [IPsec] Informal poll on IKEv2 { over TCP | fragmentation } Thread-Index: AQHOIKfGtppvcHMXwEC4ogYnb7OXPpil6qGA Date: Thu, 14 Mar 2013 19:42:29 +0000 Message-ID: References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.224.146] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ipsec@ietf.org Subject: Re: [IPsec] Informal poll on IKEv2 { over TCP | fragmentation } X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:42:40 -0000 Our answer: - I would prefer the WG to stop working on IKEv2 over TCP and instead work = on standardizing IKEv2 fragmentation paul On Mar 14, 2013, at 7:33 AM, Paul Hoffman wrote: > >=20 > It is seeming that consensus is trending towards "let's document the frag= mentation method some vendors are already doing instead of finishing IKEv2-= over-TCP", but I would like to check that. Please respond to the informal p= oll below. >=20 > --Paul Hoffman >=20 >=20 > - I would prefer the WG to continue working on IKEv2 over TCP >=20 > - I would prefer the WG to stop working on IKEv2 over TCP and instead wor= k on standardizing IKEv2 fragmentation >=20 > - I would prefer the WG to continue working on IKEv2 over TCP and also wo= rk on standardizing IKEv2 fragmentation >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From mcr@sandelman.ca Thu Mar 14 12:56:11 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F5D11E825E for ; Thu, 14 Mar 2013 12:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rim2FQwL2pHV for ; Thu, 14 Mar 2013 12:56:02 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id B980211E8258 for ; Thu, 14 Mar 2013 12:56:01 -0700 (PDT) Received: from sandelman.ca (unknown [130.129.16.118]) by relay.sandelman.ca (Postfix) with ESMTPS id E73FE22060 for ; Thu, 14 Mar 2013 19:56:00 +0000 (UTC) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 78791CA0C7 for ; Thu, 14 Mar 2013 15:56:00 -0400 (EDT) From: Michael Richardson To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 14 Mar 2013 15:56:00 -0400 Message-ID: <24816.1363290960@sandelman.ca> Sender: mcr@sandelman.ca Subject: [IPsec] BFD and IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:56:12 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Do IPsec people know about: http://datatracker.ietf.org/wg/bfd/charter/ RFC5880 Description of Working Group The BFD Working Group is chartered to standardize and support the bidirectional forwarding detection protocol (BFD) and its extensions. A core goal of the working group is to standardize BFD in the context of IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. The Working Group will also provide advice and guidance on BFD to other working groups or standards bodies as requested. =3D3D=3D3D=3D3D I don't think that this addreses any work item for IPsecME, but I thought that maybe it might help someone to know about this. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJRQitQAAoJEKD0KQ7Gj3P2mCUIAKTpEakW8H7W5ZefMD90WnFg OEJhbYHiUWqw382hhFXEmSsBWNqbmuGp2gVxEB9WHwUFH+iDcRgWKt6iSUeb/GFD PBoP31N9QDwPSuecsHANpw77GdQL1K3fU7pZ/FAynIsf5k5OrQmcBSYA6YAQPEPP 4D5Sd/9Ew9LoAtp9hi/9L/9rFur00M4RhLSi5rFWB9UYjQ9I+TrhR2SZ3ACOnmFx wF0dP09zb0tV8kq6Ifqhs1dJQKqU6CsSXw5tjhTuFa8urZlQVhO8aQDUvdz+MYz0 BjxDRLAzJ1MIem3SexQAYeoU/obHZ5rxruGW3VFkRVUVWwuw46UAaxzQ72rfDHQ= =Mbrf -----END PGP SIGNATURE----- --=-=-=-- From yaronf.ietf@gmail.com Thu Mar 14 14:13:23 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC4A11E8231 for ; Thu, 14 Mar 2013 14:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFaV7F+yFOXI for ; Thu, 14 Mar 2013 14:13:23 -0700 (PDT) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id CC59311E8228 for ; Thu, 14 Mar 2013 14:13:22 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id c41so1313453eek.41 for ; Thu, 14 Mar 2013 14:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=r+OKd1OwEM+7eK1WQD7po0aN7RMu2j5+iM93s/WbyII=; b=MTt3/0gH4MCr+sUw4e47nqtzxuqAPCzq4D2oPCVMQCq+oMcfrti8chJ1nrqDuAFvIN /VB1hXEskAsqEmQPO2KKk1vNepSeWU7v2E+Nut7O3WKbyH6bKqcbB5tEtGTEYoZoE+Gz v/LoVbrj48I7zmkt/7BP0d7m+V76lp+btsblWuJEk2D67UCHA6so6X4op/Wk/PS+ANK6 S4wMl2uH1S6I5WGjvJstJ1JjLOAnhG6fzOo9nJcJT9+yFnHCRY9kyxf7eyV4HlFqrJoc 8LzGWmu0DS8RYqHRk3/pci+E70sqLWEo0s071UzMjMf69cE6vrYBnQ8a8rJv1KVExOZz 5B+w== X-Received: by 10.14.215.193 with SMTP id e41mr10790059eep.32.1363295601958; Thu, 14 Mar 2013 14:13:21 -0700 (PDT) Received: from [10.0.0.5] (bzq-109-64-140-113.red.bezeqint.net. [109.64.140.113]) by mx.google.com with ESMTPS id 46sm6157952eea.3.2013.03.14.14.13.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 14:13:20 -0700 (PDT) Message-ID: <51423D6E.7080409@gmail.com> Date: Thu, 14 Mar 2013 23:13:18 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Paul Wouters References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> <294A12724CB849D2A33F7F80CC82426A@buildpc> <51408287.7080207@gmail.com> <3028CF35E60A40068CE70EB7BB0BDEF1@buildpc> <20801.57047.617753.249763@fireball.kivinen.iki.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" , Valery Smyslov , Yoav Nir , Tero Kivinen Subject: Re: [IPsec] IKE fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 21:13:23 -0000 Hi Paul, Can't an off-path attacker DoS the gateway if they can guess the SPI values? We never mandated that SPIs should be random (except for RFC 6290, in Sec. 9.3, but this is rarely implemented), so implementations are free to use very small integers for the SPIs. In fact I think we should reconsider mandating random SPIs once again. Thanks, Yaron On 03/14/2013 04:51 PM, Paul Wouters wrote: > On Thu, 14 Mar 2013, Tero Kivinen wrote: > >> As earlier explained not doing that allows very wasy DoS attack, which >> allows IKEv2 to finish by just sending very few packets, i.e. you send >> one corrupted fragment to the packet and if you do that before >> responder gets the correct fragment, the responder stores it for >> reassembly and after it reassembles the packet it will only then >> notice that the packet is corrupted, and then it needs to throw the >> whole packet away. It cannot know which of the fragment is corrupted. >> This means the initiator needs to retransmit whole packet, i.e. all >> fragments of it, and attacker can do this again. > > Note that requires an observer that can see your cookies/spi. Which would > mean a local attacker, whom could just as easilly send you nonsense > forged from the remote endpoint - as they are guaranteed to answer > faster. You'd be decrypting thousands of packets to find the needle in > the haystack. I wonder what the chances then are that you don't end up > dropping teh valid fragment. > > If the attacker is not local, they need to be in your path to know the > spi/cookies, and they can just filter out the valid fragments. > > But I see your point, it does raise the bar a little bit. Although I'm > not convinced it's worth it. > > Paul > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Thu Mar 14 15:01:41 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49941F0D0F for ; Thu, 14 Mar 2013 15:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zE00x4H6h7oI for ; Thu, 14 Mar 2013 15:01:41 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E77B1F0D09 for ; Thu, 14 Mar 2013 15:01:39 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r2EM0KSn019194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Mar 2013 00:00:20 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r2EM0JIm001355; Fri, 15 Mar 2013 00:00:19 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20802.18547.325537.302615@fireball.kivinen.iki.fi> Date: Fri, 15 Mar 2013 00:00:19 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: IPsecme WG Subject: [IPsec] Informal poll on IKEv2 { over TCP | fragmentation } X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 22:01:41 -0000 Paul Hoffman writes: > > > It is seeming that consensus is trending towards "let's document the > fragmentation method some vendors are already doing instead of > finishing IKEv2-over-TCP", but I would like to check that. Please > respond to the informal poll below. > > --Paul Hoffman > > - I would prefer the WG to continue working on IKEv2 over TCP > - I would prefer the WG to stop working on IKEv2 over TCP and > instead work on standardizing IKEv2 fragmentation > - I would prefer the WG to continue working on IKEv2 over TCP and > also work on standardizing IKEv2 fragmentation Either 1 or 2, but not for 3. I.e. either one is fine for me, but I do not want to have two ways of doing it in IKEv2. -- kivinen@iki.fi From bew@cisco.com Thu Mar 14 15:36:07 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2BA11E8133 for ; Thu, 14 Mar 2013 15:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fkKIvtlvSnT for ; Thu, 14 Mar 2013 15:36:07 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA5511E8173 for ; Thu, 14 Mar 2013 15:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=265; q=dns/txt; s=iport; t=1363300562; x=1364510162; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=IcsvjlqIvJXQJVNHRKbXdq0Xnsqg2j6wL5wmiAEL4QA=; b=Ash9z1RanMjfCpS/a9zb9O28+4l6+m/0iXNpHlgZSEgQBRxEznOetaa9 kUdHLZZls+5hEMIGqzVMBFPVAw86L7EtzkRzjwPkeeMGTup2dhOObKgk7 N94mWSxj74XuDcTsElBYSoNStf0WFatpRV7Y1InBOM1MjMZ6MXporoN4C c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAO9PQlGrRDoI/2dsb2JhbABDhRS/cYFnFnSCLAEBBDo/EAtGVwaIJsIQjmMzB4JfYQOWWIV9iwWDJiA X-IronPort-AV: E=Sophos;i="4.84,848,1355097600"; d="scan'208";a="72958826" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 14 Mar 2013 22:36:00 +0000 Received: from [10.21.76.164] ([10.21.76.164]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2EMZx4g011131; Thu, 14 Mar 2013 22:36:00 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Weis In-Reply-To: Date: Thu, 14 Mar 2013 18:36:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20799.34490.611737.922474@fireball.kivinen.iki.fi> To: Paul Hoffman X-Mailer: Apple Mail (2.1499) Cc: IPsecme WG Subject: Re: [IPsec] Informal poll on IKEv2 { over TCP | fragmentation } X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 22:36:07 -0000 My answer: - I would prefer the WG to continue working on IKEv2 over TCP If this is not the consensus, I agree with Yoav: I would prefer that we = clear up the situation with Microsoft's IPR before working on = standardizing IKEv2 fragmentation. Brian=