From paul.hoffman@vpnc.org Tue Nov 2 17:52:55 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5B543A69A1 for ; Tue, 2 Nov 2010 17:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.801 X-Spam-Level: X-Spam-Status: No, score=-99.801 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZwTwlR7Tekn for ; Tue, 2 Nov 2010 17:52:55 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id E31463A69A8 for ; Tue, 2 Nov 2010 17:52:54 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oA30qxKd006640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Nov 2010 17:53:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 2 Nov 2010 17:52:57 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Presentations for the upcoming IETF 79 meeting in Beijing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 00:52:55 -0000 Greetings again. The presentations for next week's meeting are available now. By all means, please review them and comment on the list *if you think there is an error or omission*. If you see something that is correct but you don't like it, *please* open a new thread for that specific topic. Agenda: QCD: HA: Note that these slides may change before the meeting: that's a good thing. Thank you to the authors for getting them to Yaron and I in advance of the meeting; few WGs have any slides available at all yet. --Paul Hoffman, Director --VPN Consortium From ynir@checkpoint.com Sun Nov 7 14:47:52 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1D93A690A for ; Sun, 7 Nov 2010 14:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-eG2deXMTFY for ; Sun, 7 Nov 2010 14:47:50 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 250733A6818 for ; Sun, 7 Nov 2010 14:47:46 -0800 (PST) X-CheckPoint: {4CD72A05-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oA7MlUmU004607 for ; Mon, 8 Nov 2010 00:48:05 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 8 Nov 2010 00:47:57 +0200 From: Yoav Nir To: IPsecme WG Date: Mon, 8 Nov 2010 00:47:55 +0200 Thread-Topic: [core] Review of draft-ietf-core-coap-03 Thread-Index: Act+zdIJOtWqZpwRRAaschp0QOofiQ== Message-ID: <45E31B75-5904-4758-AADF-90E8B8C3855A@checkpoint.com> References: 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Fwd: [core] Review of draft-ietf-core-coap-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 22:47:52 -0000 Hi all The message below is Ekr's review of the CoAP draft. The IPsec part (relate= s mostly to section 10.1) might be of interest to this working group. I'd go further than Ekr, and say that IPsec should not be used without IKE. I'm not sure whether or not section 10.1 is there because they actually int= end people to use IPsec to secure CoAP in its intended environment, or whet= her it is just there to "not leave any stone unturned". Certainly DTLS is d= escribed in much more detail, while section 10.1 reminds me of some old sec= urity considerations sections saying "just use IPsec". Begin forwarded message: > From: Eric Rescorla > Date: November 7, 2010 11:28:49 PM GMT+02:00 > To: "core@ietf.org" > Subject: [core] Review of draft-ietf-core-coap-03 >=20 > I've reviewed this document. Comments below. >=20 > My concerns here are primarily about the security parts, which seem a > bit handwavy. It's certainly possible to build systems where all the > security provided by channel security mechanisms (IPsec and DTLS) but > can't tell if this is such a system without more security analysis. >=20 > In particular: > - What's the general trust model in terms of the relationship between > the servers and clients? > - What are the assumed capabilities of the devices in question? > - How is access control expected to behave with respect to proxy caches? > (The HTTP story is clear but you've stripped out the HTTP access > control mechanisms). I don't see how a server even verifies a > client who goes through a cache. > - I'd like to see some discussion of cross-protocol attacks, which=20 > seem likely with the NoSec mode. >=20 > IPsec > You don't actually say this, but I'm assuming that you intend to > use IPsec's manual keying mode, rather than IKE. If so, this seems > to have a series of obvious problems around the lack of guaranteed > fresh keys/nonces, as well as replay attacks. In particular, if > you're going to have single-packet messages which control network > devices, it seems like anti-replay is very important, but RFC 4303 > says: >=20 > If the key used to compute an ICV is manually distributed, a > compliant implementation SHOULD NOT provide anti-replay service. If > a user chooses to employ anti-replay in conjunction with SAs that are > manually keyed, the sequence number counter at the sender MUST be > correctly maintained across local reboots, etc., until the key is > replaced. (See Section 5.) >=20 > This seems like a fairly problematic combination and at minimum > needs some discussion. >=20 > I'm similarly concerned about the use of CCM, which fails > catastrophically in the face of replayed packets. I'd like to > understand how you're going to assure that the nonce is never replayed > in the face of very long-lived keys used throughout a large network. > Recall that the birthday limit for AES-CCM in ESP is only 2^{32} > packets, but even that's for ~0.5 probability of replay. The security > is weakened long before that. >=20 > IMO it's very unwise to use ESP this way w/o at minimum some form of > automatic key diversification. >=20 >=20 > DTLS > The claim that DTLS is an order of magnitude more complicated than CoAP > is unsupported and, for instance, if we're just counting pages that doesn= 't > appear to be correct. Certainly, if you just do TLS_PSK modes, that's > not correct. In my experience, the majority of the code in a TLS stack > is the crypto algorithms and the certificate processing. You will > need the crypto algorithms in any case and the PSK profile you have > chosen does not require certificates. If this is the basis for thinking > that DTLS inadequate, you may want to rethink that. Regardless, please > please remove this claim. >=20 > Similarly, I don't know what "appreciable handshake overhead" means. > Please provide some measurements for the profile you have chosen or > remove this as well. >=20 > The particular TLS PSK mode you specify has no private entropy other than= =20 > from the shared key. If you are going to select this mode, you need=20 > language about the minimum entropy of the PSK. This is an issue for > IPsec as well, btw. >=20 > The PSK modes are not specified in 5246, so please fix this citation. >=20 > Throughout the document you write "cypher suite". The TLS term is "cipher= suite" >=20 > The question of whether you should use certs is quasi-orthogonal to wheth= er > you use TLS_RSA_PSK. You can use self-signed certs with TLS_RSA_PSK. >=20 >=20 > S 10.3.1. > This seems kind of superfluous. Code in general has bugs and it's not > clear that "stringent tests" are that useful for finding them. >=20 >=20 >=20 > -Ekr From paul.hoffman@vpnc.org Mon Nov 8 01:46:05 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFF3828C105 for ; Mon, 8 Nov 2010 01:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.8 X-Spam-Level: X-Spam-Status: No, score=-100.8 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HD2sb0JiyFbw for ; Mon, 8 Nov 2010 01:46:05 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 30C8F28C0F2 for ; Mon, 8 Nov 2010 01:46:05 -0800 (PST) Received: from [130.129.55.1] (dhcp-25eb.meeting.ietf.org [130.129.37.235]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oA89kJPp066957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 8 Nov 2010 02:46:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 8 Nov 2010 17:46:16 +0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] New agenda uploaded X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 09:46:05 -0000 IPsecME WG IETF 79, Beijing Wed., 10 Nov. 2010, 13:00-15:00 Agenda and document status - 10 min Open issues found at Failure detection open issues - 45 min High availability protocol open issues - 45 min Other topics (IPsec-related work in other WGs and so on) - 20 min Slides are at --Paul Hoffman, Director --VPN Consortium From zhangdacheng@huawei.com Tue Nov 9 17:18:40 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64F13A69C6 for ; Tue, 9 Nov 2010 17:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=1.602, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBx3MjWmK4Wm for ; Tue, 9 Nov 2010 17:18:40 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [58.251.152.66]) by core3.amsl.com (Postfix) with ESMTP id EAF893A69BA for ; Tue, 9 Nov 2010 17:18:39 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBN0060VABO2I@szxga03-in.huawei.com> for ipsec@ietf.org; Wed, 10 Nov 2010 09:19:00 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBN001TKABOK2@szxga03-in.huawei.com> for ipsec@ietf.org; Wed, 10 Nov 2010 09:19:00 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [130.129.116.202]) by szxmc04-in.huawei.com (mshttpd); Wed, 10 Nov 2010 09:19:00 +0800 Date: Wed, 10 Nov 2010 09:19:00 +0800 From: zhangdacheng 00133208 In-reply-to: <4C91E809.1080806@gmail.com> To: Yaron Sheffer Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <4C8DE47A.6060005@gmail.com> <04BD913C7AD1B84297D26D5614FBE133017B4491@XMB-BGL-417.cisco.com> <4C91E809.1080806@gmail.com> Cc: IPsecme WG Subject: [IPsec] two questions with the HA solution draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 01:18:41 -0000 Hello everybody: During the discussion of the HA solution draft, we realized there may be still some issues we have to carefully consider in the design of the synchronization solution for IPsec replay counters. 1. whether a cluster member needs to send the delta increment of the *outgoing* SAs or just unilaterally increments its counters. 2. How the user can calculate the the delta increment of its *outgoing* SAs? To find out a proper delta increment value, the user may have to know when the last synchronization between cluster memebers was undertaken so so to reason how many packets it has sent out using every SA. However, there is no such disucssion in the draft. So, what do you think of it? BR Dacheng On 11/09/2010 09:51 PM, Yoav Nir wrote: > I think so, but I also think that this deserves an issue. > > On Nov 9, 2010, at 6:42 PM, Yaron Sheffer wrote: > > > Hi Dacheng, Yoav, > > > > Now I'm confused myself. It seems to me that instead of sending the > > delta value of the outgoing replay counter, we should have sent the > > requested delta increment of the *incoming* SAs. The cluster doesn't > > need any signaling for its outgoing ESP traffic, it can just > > unilaterally increment its counters. What do you think? > > > > Thanks, > > Yaron > > > > > > On 11/09/2010 05:07 PM, zhangdacheng 00133208 wrote: > >> Hi, Yaron: > >> > >> I feel a little confused on a problem and hope to get your help. My > question is how a user know the deta of the outgoing counter value. I > can understand that a new active member know the time period between > the last synchorizaiton and the occurance of the failure so that it > can estimate how many packets the previous member has sent during the > period and how big a delta value shoudl be. However, a user does not > hav such knowledge. Howe can i > >> t find out how much the incoming counter of the cluster member > should increase? > >> > >> Cheers > >> > >> Dacheng > > > > Scanned by Check Point Total Security Gateway. > From kivinen@iki.fi Wed Nov 10 02:57:09 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B63413A697D for ; Wed, 10 Nov 2010 02:57:09 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PycWgrrdbheV for ; Wed, 10 Nov 2010 02:57:08 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C735C3A6869 for ; Wed, 10 Nov 2010 02:57:07 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id oAAAvUW2025284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Nov 2010 12:57:30 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id oAAAvT3r025647; Wed, 10 Nov 2010 12:57:29 +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: <19674.31385.954292.715081@fireball.kivinen.iki.fi> Date: Wed, 10 Nov 2010 12:57:29 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 9 min Subject: [IPsec] Comments about draft-ietf-ipsecme-failure-detection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 10:57:09 -0000 I did review the draft-ietf-ipsecme-failure-detection before the WG meeting and some of the comments I have here already have tickets so no need to add them second time: ---------------------------------------------------------------------- Comments to draft-ietf-ipsecme-failure-detection: Section 1: "However, in many cases the rebooted peer is a VPN gateway that protects only servers, " What is that supposed to mean? Section 2: "Those "at least several minutes" are a time during part of which both peers are active, but IPsec cannot be used." Not true! It is the time during one of the peer is active and another one is rebooting and the rebooting device might even get up before the time runs out as is described next few paragraphs. I suggest removing whole sentence. Section 2: "[RFC5996] does not mandate any time limits, but it is possible that the peer will start liveness checks even before the other end is sending INVALID_SPI notification, as it detected that the other end is not sending any packets anymore while it is still rebooting or recovering from the situation." I think "but it is possible that the peer will start ..." is wrong, more like "good implementation will start ...". If implementation supports black hole detection there is no point of doing that with long timeouts, as I said in our implementation that specific timeout is 10 seconds (i.e. around 20 times RTT which means with normal TCP etc traffic it never triggers, but will trigger very quickly after other end goes silent). Section 3: I still think the protocol would be much easier to implement if we limit the QCD Token Taker role for initiator and Token maker role for responder. There is no point of making the protocol very generic, as implementation are not going to implement features before there is real use scenario for it. This means even if document describes how it can be done it does not help as implementations do not support it. If someone finds real use scenario where it is needed for responder for being token taker then writing new specification for that is way faster than to get the implementations modified. I have not yet seen use scenario for that where QCD would help (meaning there are other already standardized ways in IKEv2 which are faster and more efficient implemented in implementations). Section 4.2: "The QCD_TOKEN notification is related to the IKE SA and MUST follow the AUTH payload and precede the Configuration payload and all payloads related to the child SA." RFC5996 removed payload ordering restrictions, so why are we adding them back here? I suggest removing the whole paragraph. Section 5.2: I would remove this whole section. Section 7: I would remove this whole section. It was good to be there, but I do not think we need it anymore. At least section 7.4 is still completely wrong and is already covered by the section 2. Section 8: "Before establishing a new IKE SA using Session Resumption, a client should ascertain that the gateway has indeed failed. This could be done using either a liveness check (as in RFC 5996) or using the QCD tokens described in this document." How do you use QCD tokens to ascertain that the gateways has indeed failed. If you receive QCD token then you know that other end is dead, but to receive QCD token the active operation you do is to send liveness check. I think this sentence requires some rewrite. Section 8: Example is wrong. The HDR, {} --> <-- HDR, N(QCD_TOKEN) should be HDR, SK{} --> <-- HDR, N(INVALID_IKE_SPI), N(QCD_TOKEN) Section 9.1: "Implementing the "token maker" side of QCD makes sense for IKE implementation where protected connections originate from the peer, such as inter-domain VPNs and remote access gateways. Implementing the "token taker" side of QCD makes sense for IKE implementations where protected connections originate, such as inter-domain VPNs and remote access clients." So token maker and toker are both used "where protected connections originate"? What is the difference? This text requires clarifications. Section 9.1: "To clarify the this discussion:" ^^^^^^^^ Section 9.1: "o For inter-domain VPN gateway it makes sense to implement both roles, because it can't be known in advance where the traffic originates." I do not really see that. For Inter-Domain VPN gateways there is two possibilities: symmetric or asymmetric initiation. I.e. in asymmetric situation only one end can initiate connections (for example because it is behind NAT or similar or because the HQ VPN server is always configured to be responder). In that case the Inter-Domain VPN case is similar to the remote-access client / gateway case, i.e. the "initiator end of Inter-Domain VPN gateway" is same as "remote-access client" and "Responder end of the Inter-Domain VPN Gateway" is same as "remote-access server". For symmetric situations where either end can initiate connections there are better and faster ways to handle things, as I have already described earlier. Section 10.1: "Specifically, if one taker does not properly secure the QCD tokens and an attacker gains access to them, this attacker MUST NOT be able to guess other tokens generated by the same maker." Is bit misleading, as for attacker it is trivial to get large amount of tokens. It just need to send one faked IKE SA packet to token maker with random IKE SPIs to get valid token for that IKE SPI pair. Section 10.3: "An attacker may try to attack QCD if the generation algorithm described in Section 5.1 is used." I do not think there is that big difference between 5.1 and 5.2 in here. The 5.2 will limit the dictionary for one IP address, but as it is already impossibly large it does not matter. I would suggest removing the reference to 5.1 in first sentece. Section 10.4: Needs also comment that the load balancer switch demuxing MUST stay stable. I.e. it can never change. Especially it cannot change even when one devices goes off-line. Also there MUST NOT be a way to bypass the load balancer using whether methods possible (including tunneling packets in some other tunneling protocolos, adding routing headers etc). I would add even more warning that this setup is extremly dangeours. Luckily section 10.2 already forbids this: "This document does not specify how a load sharing configuration of IPsec gateways would work, but in order to support this specification, all members MUST be able to tell whether a particular IKE SA is active anywhere in the cluster. One way to do it is to synchronize a list of active IKE SPIs among all the cluster members." -- kivinen@iki.fi From kivinen@iki.fi Wed Nov 10 03:03:38 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 977523A6849 for ; Wed, 10 Nov 2010 03:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-FJaYCDidQX for ; Wed, 10 Nov 2010 03:03:37 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 324A83A6807 for ; Wed, 10 Nov 2010 03:03:37 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id oAAB43nO000317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Nov 2010 13:04:03 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id oAAB43fD026912; Wed, 10 Nov 2010 13:04:03 +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: <19674.31779.119242.979171@fireball.kivinen.iki.fi> Date: Wed, 10 Nov 2010 13:04:03 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 6 min Subject: [IPsec] New item for draft-ietf-ipsecme-failure-detection-02.xt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 11:03:38 -0000 I started to think whether there are other possible attacks against QCD and found one which might be possible if implementations do not take care of it. The IKE SPIs are allocated during the IKE_SA_INIT. The IKEv2 SA is really created during the IKE_AUTH. This means there is a possibility that some implementation might consider IKE SA spis still invalid before the IKE_AUTH finishes (for example another member of the tight cluster might be updated with the IKE SA information only after the IKE SA is ready). If attacker sees IKE_SA_INIT and grabs IKE SAs from there and then sends IKE packet to that another member which has not yet updated with this partial IKE SA that might trigger QCD_TOKEN even when it should not. This is not really big issue as in normal implementations already take care of this by following the rule which says do not allow any other exchanges before IKE_SA_INIT/IKE_AUTH finishes but this might happen on certain cluster setups. -- kivinen@iki.fi From kivinen@iki.fi Wed Nov 10 03:18:11 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2CE33A6901 for ; Wed, 10 Nov 2010 03:18:11 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSX86yOcLA5E for ; Wed, 10 Nov 2010 03:18:10 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 5A1AB3A6807 for ; Wed, 10 Nov 2010 03:18:10 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id oAABIatk027017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Nov 2010 13:18:36 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id oAABIYo3019839; Wed, 10 Nov 2010 13:18:34 +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: <19674.32650.588044.52254@fireball.kivinen.iki.fi> Date: Wed, 10 Nov 2010 13:18:34 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 14 min Subject: [IPsec] draft-ietf-ipsecme-ipsecha-protocol-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 11:18:11 -0000 I haven't had time to read the draft-ietf-ipsecme-ipsecha-protocol-02 completely yet, but while looking at the slides in the WG meeting, I noticed one serious problem. The IKEV2_MESSAGE_ID_SYNC and IPSEC_REPLAY_COUNTER_SYNC messages do not follow Notification payload syntax. For the IKEV2_MESSAGE_ID_SYNC there is only the missing critical bit: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... instead of: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For the IPSEC_REPLAY_COUNTER_SYNC it is bit more serious as it puts something else on the same plaCe where the C bit normally is: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |E| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I.e it adds "ESN bit" on the generic IKEv2 header in the location where normally there is the critical bit. There is not really any need for the ESN bit as the length of the delta value can be seen from the payload length field. ---------------------------------------------------------------------- Also the section 7 says: The Message ID value used in the Informational exchange that contains the IKEV2_MESSAGE_ID_SYNC notification MUST be zero so that it is not validated upon receipt as required by normal IKEv2 windowing. The Message ID zero MUST be accepted only in an Informational exchange that contains a notification of type IKEV2_MESSAGE_ID_SYNC. If any Informational exchange has a Message ID zero, but not this notification type, such messages MUST be discarded upon decryption and the INVALID_SYNTAX notification SHOULD be sent. Other payloads MUST NOT be sent in this Informational exchange. Whenever an IKEV2_MESSAGE_ID_SYNC or IPSEC_REPLAY_COUNTER_SYNC notification payload is received with an invalid failover count or invalid nonce data, the event SHOULD be logged. Message ID zero is completely valid and legal value for message ID and this text suddenly makes it impossible to use it anymore. The first message responder ever always has Message ID zero, which means that if you follow this then first message sent by responder will be rejected. Message ID is also zero after IKE SA rekey. Also INVALID_SYNTAX notification do have some special meaning in RFC5996: Only authentication failures (AUTHENTICATION_FAILED and EAP failure) and malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without requiring an explicit INFORMATIONAL exchange carrying a Delete payload. .... If a peer parsing a request notices that it is badly formatted (after it has passed the message authentication code checks and window checks) and it returns an INVALID_SYNTAX notification, then this error notification is considered fatal in both peers, meaning that the IKE SA is deleted without needing an explicit Delete payload. -- kivinen@iki.fi From yaronf.ietf@gmail.com Thu Nov 11 07:16:10 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 028B53A6970 for ; Thu, 11 Nov 2010 07:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.34 X-Spam-Level: X-Spam-Status: No, score=-102.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aulG7A2eKbfy for ; Thu, 11 Nov 2010 07:16:09 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id E573E3A6948 for ; Thu, 11 Nov 2010 07:16:08 -0800 (PST) Received: by wwb29 with SMTP id 29so160451wwb.13 for ; Thu, 11 Nov 2010 07:16:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=rLj4n4vGGf8nf9N0NDIwiJo/r3ic1bXbXV9rFiNkGn4=; b=lURLehZBkGf56zTbG3Wg8z1XQ/55NUyZozY7IjwiWrjFidEbnXdRJqe9ph+LB1KHyI Rov8xsDN4WQLj606OIADiReyCiS0UNwEqpT0bayURk5Z2Tq6yYq4FWk8S1BWKviHDdbS rHAd34Bvgs7uSPHYzuekIu4094xTXb25refKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=nMLMXfhc8ZammeOCXj/uHE22Wadfx7CccEKyjybFddPKYITHo8s2EeL46hk03ntxE6 MhbLNPjC7b/VvAF18fUvp8v/wKsMbVlHS/m1PNWi1tqiknKR+4ZRaS/dKNfkrTTpj0xw bqYTOyVerp/las7tKXJqmMsaMef5WCM3F+RKs= Received: by 10.227.157.85 with SMTP id a21mr980215wbx.95.1289488598258; Thu, 11 Nov 2010 07:16:38 -0800 (PST) Received: from [10.0.0.2] (bzq-79-181-26-165.red.bezeqint.net [79.181.26.165]) by mx.google.com with ESMTPS id h29sm1791493wbc.9.2010.11.11.07.16.35 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 07:16:37 -0800 (PST) Message-ID: <4CDC08CF.8030106@gmail.com> Date: Thu, 11 Nov 2010 17:16:31 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 15:16:10 -0000 Hi, it seems to me we have created an overly complicated solution for replay protection of the Msg ID = 0 messages. Specifically, I think both the failover counter and the nonce can be eliminated. Since the messages are protected under the IKE SA, we just need to ensure that in a correct run of the protocol, there is never any need to repeat previous messages. This can be done by including *both* Msg ID counters in each message, and specifying a few rules to make sure counters never go backwards. Cluster member to client: - The counter I plan to use next (based on a traffic/rekey rate estimate, must be higher than the last message that was actually sent, otherwise it might be rejected) - The counter I think you will use next (the last known value, as received from the failed cluster member) Client to cluster: - The counter I really plan to use next (must be equal to or higher than the received value) - The counter you said you will use next And each side must accept incoming messages only if both values are equal to or larger than the corresponding one previously received from the same peer, and one of them is strictly larger than the previous value. Am I missing anything? Thanks, Yaron From fd@cisco.com Thu Nov 11 19:55:47 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8AA13A692F for ; Thu, 11 Nov 2010 19:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_25=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVaOJqJSbeZy for ; Thu, 11 Nov 2010 19:55:46 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 415873A67B8 for ; Thu, 11 Nov 2010 19:55:46 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAC3ivle005255; Fri, 12 Nov 2010 04:44:57 +0100 (CET) Received: from [10.40.72.195] ([10.79.100.66]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAC3inKS000558; Fri, 12 Nov 2010 04:44:51 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Frederic Detienne In-Reply-To: Date: Fri, 12 Nov 2010 11:44:48 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <76757468-A501-4342-A1FC-70F0E0F9991D@cisco.com> References: <4C8DE47A.6060005@gmail.com> <04BD913C7AD1B84297D26D5614FBE133017B4491@XMB-BGL-417.cisco.com> <4C91E809.1080806@gmail.com> To: zhangdacheng 00133208 X-Mailer: Apple Mail (2.1081) Cc: IPsecme WG , Pratima Sethi Subject: Re: [IPsec] two questions with the HA solution draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 03:55:47 -0000 Hi Dacheng, following our discussion, we kept evaluating the proposal we think it is = simpler to send the absolute values. 1) Delta computation The whole computation would go as such: Head-end sends (Rx.s, Tx.s) (s for "server") to the client. Client computes Rx.delta =3D Tx.c - Rx.s (c for client) Client computes Tx.delta =3D Rx.c - Tx.s If Tx.delta > 0, the head-end needs to adjust its Tx. If Rx,delta > 0, the head-end needs to adjust its Rx. If the servers are already synchronized, there is a chance that Rx.delta = =3D=3D0 and Tx.delta =3D=3D 0 (especially Tx). The cases where Rx.delta < 0 and Tx.delta < 0 seem odd and probably = deserve some logging. 2) message format Since the head-end sends absolute values, we think that the client = should also send absolute values for readability. 3) replay attack window Also following our live discussion, we think that the draft should = recommend stopping all IPsec input handling as long as the IPsec sync = exchange is not complete. Otherwise, there is a small but very real = window of opportunity for replay. We think this should be recommended as a "SHOULD" so to make it a = configuration option to the user or implementer. Regards, fred On 10 Nov 2010, at 09:19, zhangdacheng 00133208 wrote: > Hello everybody: >=20 > During the discussion of the HA solution draft, we realized there may = be still some issues we have to carefully consider in the design of the = synchronization solution for IPsec replay counters. >=20 > 1. whether a cluster member needs to send the delta increment of the = *outgoing* SAs or just unilaterally increments its counters.=20 > 2. How the user can calculate the the delta increment of its = *outgoing* SAs? To find out a proper delta increment value, the user may = have to know when the last synchronization between cluster memebers was = undertaken so so to reason how many packets it has sent out using every = SA. However, there is no such disucssion in the draft. >=20 > So, what do you think of it? >=20 > BR >=20 > Dacheng=20 >=20 > On 11/09/2010 09:51 PM, Yoav Nir wrote: >> I think so, but I also think that this deserves an issue. >>=20 >> On Nov 9, 2010, at 6:42 PM, Yaron Sheffer wrote: >>=20 >>> Hi Dacheng, Yoav, >>>=20 >>> Now I'm confused myself. It seems to me that instead of sending the >>> delta value of the outgoing replay counter, we should have sent the >>> requested delta increment of the *incoming* SAs. The cluster doesn't >>> need any signaling for its outgoing ESP traffic, it can just >>> unilaterally increment its counters. What do you think? >>>=20 >>> Thanks, >>> Yaron >>>=20 >>>=20 >>> On 11/09/2010 05:07 PM, zhangdacheng 00133208 wrote: >>>> Hi, Yaron: >>>>=20 >>>> I feel a little confused on a problem and hope to get your help. My=20= >> question is how a user know the deta of the outgoing counter value. I=20= >> can understand that a new active member know the time period between=20= >> the last synchorizaiton and the occurance of the failure so that it=20= >> can estimate how many packets the previous member has sent during the=20= >> period and how big a delta value shoudl be. However, a user does not=20= >> hav such knowledge. Howe can i >>>> t find out how much the incoming counter of the cluster member=20 >> should increase? >>>>=20 >>>> Cheers >>>>=20 >>>> Dacheng >>>=20 >>> Scanned by Check Point Total Security Gateway. >>=20 >=20 >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Sat Nov 13 00:40:14 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAB503A6AB1 for ; Sat, 13 Nov 2010 00:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.432 X-Spam-Level: X-Spam-Status: No, score=-100.432 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7-I3QfqWVDr for ; Sat, 13 Nov 2010 00:40:14 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 1492E3A6A9C for ; Sat, 13 Nov 2010 00:40:13 -0800 (PST) Received: from [130.129.72.80] (dhcp-4850.meeting.ietf.org [130.129.72.80]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oAD8ekfS038766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Nov 2010 01:40:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sat, 13 Nov 2010 16:40:44 +0800 To: "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Review of PF_KEY extension X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 08:40:15 -0000 Julien tells me that no one has responded to them. Is there no one here interested in PFKEY any more? --Paul Hoffman At 9:40 AM -0700 10/20/10, Laganier, Julien wrote: >Folks, > >We are trying to get this PF_KEY extension document published as an Informational RFC and it would be beneficial if some IPsec experts on this list could help us by reviewing the document. > >Please let me know if you are willing to review the document. > >Thanks. > >--julien > > >PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE > draft-ebalard-mext-pfkey-enhanced-migrate-01 > >Abstract > > This document describes the need for an interface between Mobile IPv6 > and IPsec/IKE and shows how the two protocols can interwork. An > extension of the PF_KEY framework is proposed which allows smooth and > solid operation of IPsec/IKE in a Mobile IPv6 environment. > > PF_KEY MIGRATE message serves as a carrier for updated information > for both the in-kernel IPsec structures (Security Policy Database / > Security Association Database) and those maintained by the key > managers. This includes in-kernel Security Policy / Security > Association endpoints, key manager maintained equivalents, and > addresses used by IKE_SA (current and to be negotiated). The > extension is helpful for assuring smooth interworking between Mobile > IPv6 and IPsec/IKE for the bootstrapping of mobile nodes and their > movements. From yaronf.ietf@gmail.com Mon Nov 15 00:06:17 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8C03A6A94 for ; Mon, 15 Nov 2010 00:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_25=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cRwqVHqpNRC for ; Mon, 15 Nov 2010 00:06:13 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 8A2833A6B9D for ; Mon, 15 Nov 2010 00:06:12 -0800 (PST) Received: by wwb29 with SMTP id 29so1038557wwb.13 for ; Mon, 15 Nov 2010 00:06:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=pqwMhm5oPjtWTVLpo2j+5Bon+/UIqbZRYSgOySPzh7I=; b=jkjyDBep/u8memTmwYeNd0Am9LPZOKTtYG9Qqc2ndb7VFNTrhAqHeIw3TWBTA/uQOY IsviEBIQjk8xctC90OuIc4+wKiRXiY9YD2QhJlfNi2Snhax7ki0aKUHmwKLN08znzTv8 M67Tv4emiy70URlSTUqo9/zXcJqMlbyuySxk4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=itvWTpdWLgUI9o790dLD4wUUbIkvoSchqi/UQy9KWMy7iYKayTswYzDvpSxAzfLw3i C+orRaLH3pKnppyKgBrovFpYuGbluln6vxqtObGLnC2hprNWuDh7bteENeOgBdj7nytl IcJSbr/3Kd++azAhEyo1BXnD57zbx18JWboCY= Received: by 10.227.133.132 with SMTP id f4mr5720962wbt.60.1289808412541; Mon, 15 Nov 2010 00:06:52 -0800 (PST) Received: from [10.0.0.1] (bzq-79-178-2-190.red.bezeqint.net [79.178.2.190]) by mx.google.com with ESMTPS id i19sm4859443wbe.17.2010.11.15.00.06.49 (version=SSLv3 cipher=RC4-MD5); Mon, 15 Nov 2010 00:06:51 -0800 (PST) Message-ID: <4CE0EA18.4070807@gmail.com> Date: Mon, 15 Nov 2010 10:06:48 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Frederic Detienne References: <4C8DE47A.6060005@gmail.com> <04BD913C7AD1B84297D26D5614FBE133017B4491@XMB-BGL-417.cisco.com> <4C91E809.1080806@gmail.com> <76757468-A501-4342-A1FC-70F0E0F9991D@cisco.com> In-Reply-To: <76757468-A501-4342-A1FC-70F0E0F9991D@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , zhangdacheng 00133208 , Pratima Sethi Subject: Re: [IPsec] two questions with the HA solution draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 08:06:17 -0000 Hi Fred, the main reason why we chose delta values over absolute values is scalability: there may be a large number of IPsec SAs under any IKE SA. It is not important to strictly synchronize the counters, what's important is just to minimize packet loss. So the easiest way is to increment *all* the SAs by a single delta value. Regarding replay protection during the exchange: what you are mandating here is to drop all incoming packets for 1 RTT, for all clients connected to a cluster. This may be acceptable in some deployments, and may be out of the question in others. So I suggest to clarify this choice in the document, but to keep it as a local policy decision rather than a MUST or SHOULD. Thanks, Yaron On 11/12/2010 05:44 AM, Frederic Detienne wrote: > Hi Dacheng, > > following our discussion, we kept evaluating the proposal we think it > is simpler to send the absolute values. > > 1) Delta computation > > The whole computation would go as such: > > Head-end sends (Rx.s, Tx.s) (s for "server") to the client. > > Client computes Rx.delta = Tx.c - Rx.s (c for client) > > Client computes Tx.delta = Rx.c - Tx.s > > If Tx.delta> 0, the head-end needs to adjust its Tx. > > If Rx,delta> 0, the head-end needs to adjust its Rx. > > If the servers are already synchronized, there is a chance that > Rx.delta ==0 and Tx.delta == 0 (especially Tx). > > The cases where Rx.delta< 0 and Tx.delta< 0 seem odd and probably > deserve some logging. > > 2) message format > > Since the head-end sends absolute values, we think that the client > should also send absolute values for readability. > > 3) replay attack window > > Also following our live discussion, we think that the draft should > recommend stopping all IPsec input handling as long as the IPsec sync > exchange is not complete. Otherwise, there is a small but very real > window of opportunity for replay. > > We think this should be recommended as a "SHOULD" so to make it a > configuration option to the user or implementer. > > Regards, > > fred > > > On 10 Nov 2010, at 09:19, zhangdacheng 00133208 wrote: > > > Hello everybody: > > > > During the discussion of the HA solution draft, we realized there > may be still some issues we have to carefully consider in the design > of the synchronization solution for IPsec replay counters. > > > > 1. whether a cluster member needs to send the delta increment of the > *outgoing* SAs or just unilaterally increments its counters. > > 2. How the user can calculate the the delta increment of its > *outgoing* SAs? To find out a proper delta increment value, the user > may have to know when the last synchronization between cluster > memebers was undertaken so so to reason how many packets it has sent > out using every SA. However, there is no such disucssion in the draft. > > > > So, what do you think of it? > > > > BR > > > > Dacheng > > > > On 11/09/2010 09:51 PM, Yoav Nir wrote: > >> I think so, but I also think that this deserves an issue. > >> > >> On Nov 9, 2010, at 6:42 PM, Yaron Sheffer wrote: > >> > >>> Hi Dacheng, Yoav, > >>> > >>> Now I'm confused myself. It seems to me that instead of sending the > >>> delta value of the outgoing replay counter, we should have sent the > >>> requested delta increment of the *incoming* SAs. The cluster doesn't > >>> need any signaling for its outgoing ESP traffic, it can just > >>> unilaterally increment its counters. What do you think? > >>> > >>> Thanks, > >>> Yaron > >>> > >>> > >>> On 11/09/2010 05:07 PM, zhangdacheng 00133208 wrote: > >>>> Hi, Yaron: > >>>> > >>>> I feel a little confused on a problem and hope to get your help. My > >> question is how a user know the deta of the outgoing counter value. I > >> can understand that a new active member know the time period between > >> the last synchorizaiton and the occurance of the failure so that it > >> can estimate how many packets the previous member has sent during the > >> period and how big a delta value shoudl be. However, a user does not > >> hav such knowledge. Howe can i > >>>> t find out how much the incoming counter of the cluster member > >> should increase? > >>>> > >>>> Cheers > >>>> > >>>> Dacheng > >>> > >>> Scanned by Check Point Total Security Gateway. > >> > > > > > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > From yaronf.ietf@gmail.com Wed Nov 17 22:49:22 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2873A67F2 for ; Wed, 17 Nov 2010 22:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, SARE_WEOFFER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fh+K82RwQco for ; Wed, 17 Nov 2010 22:49:12 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 5DF533A67E3 for ; Wed, 17 Nov 2010 22:49:11 -0800 (PST) Received: by wwa36 with SMTP id 36so2873628wwa.13 for ; Wed, 17 Nov 2010 22:49:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=M2HQuUppNsI2eVROv60rxPJ1LDoKx3+1cfEf2kjTPOs=; b=FD7Ay7TmwJw1X6bF7MgAjvgeRmHKu1z0gTMnH5ZdvVJNru04ikbNrz6LV1wisD83wR 83CS+3e8CKDs2HGevVw7L1R0ZVz70bG4HCmsVXBNLWTKyImkVR3yOOva/D5f7+p0uhlP /sCtvZ6HbFPrqOkNI7oGeDKtwygK+Z7zYpORU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=hDCb2HyI8085WdTssnqNKnF3qh9Aa/V8hn/EBtTNcbE4Uh/5Z3L7dw5T0x1PWdYaHi MWVfWBlaLQ6cmZJHXkMKN1Xvt/vqtEYjvOY0IWk6BrQwCO5mwFKue9C+hN737C2Lmc1n xNoWYIbDjPa0ApI4NX+XDZbM8OOB2KHxFsohs= Received: by 10.227.152.8 with SMTP id e8mr192879wbw.175.1290062997191; Wed, 17 Nov 2010 22:49:57 -0800 (PST) Received: from [10.0.0.1] (bzq-79-181-24-102.red.bezeqint.net [79.181.24.102]) by mx.google.com with ESMTPS id i19sm33466wbe.11.2010.11.17.22.49.50 (version=SSLv3 cipher=RC4-MD5); Wed, 17 Nov 2010 22:49:55 -0800 (PST) Message-ID: <4CE4CC87.6090302@gmail.com> Date: Thu, 18 Nov 2010 08:49:43 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [IPsec] Draft IETF-79 minutes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 06:49:23 -0000 Below are draft minutes of the Beijing meeting, for your review. I'd like to thank Brian Weis for taking them. I have meddled with the text, so all remaining errors are mine. Thanks, Yaron --- WG Status - Paul Hoffman (PH) Slides: http://www.ietf.org/proceedings/79/slides/ipsecme-0.pdf PH: The two active documents in the WG will be presented today. We assume that people have read the docs and are aware of the open issues (http://trac.tools.ietf.org/wg/ipsecme/trac/report/1). Failure Detection - Frederick Detienne (FD) Slides: http://www.ietf.org/proceedings/79/slides/ipsecme-2.pdf FD: By taking parameters on the wire and the QCD Secret (not shared), a QCD token is created. The Token is sent in the IKE_AUTH exchange. The peer also returns a QCD token that it has similarly generated. If one of the VPN gateways crashes, it loses its information except for its QCD Secret. It will receive ESP packets from the still-live peer, and returns an INVALID_SPI as well as a token sent in the clear. The non-crashed peer sends an IKE message back containing just a header (liveness test), which allows the crashed peer to re-create its token. Q: Header isn't protected? A: This is the gist of the issue we'll be covering later. Issue 198: Do we really need the QCD token for the initiator too? Tero Kivinen (TK): I don't believe that to be relevant to this case. QCD is useful for the asymmetric case. Otherwise, the gateway that restarts can recreate the SA. Paul: we included the gw-gw case in the problem statement. TK: Making it symmetrical adds lots of complication to implementations, in particular when there's mobility involved. FD: On the contrary. Going asymmetric forces users to configure which side is doing QCD. In practice, this is a real problem ... I have seen many customer cases over the years and this is a big problem. Failure detection turns a high severity problem into a low-severity or a non-problem. Paul: Tero, what you're saying is that because this doesn't happen much, and it's a fair amount of implementation overhead, you'd like to remove this case? TK: Yes. Most of our gw-gw cases there are better and faster recovery methods. PH: But Fred, you're saying that if you don't cover this, then you have to configure more. FD: Yes, you have to make a judgment call re: which side initiates. TK: In those cases where it matters, only one one side can do QCD anyway. PH: You're way oversimplifying. TK: It's usually the branch office that drops off, and the headend doesn't care. You can use other methods that are faster to fix this problem. Most problems are a result of bad implementations. Paul: Are we at the right scenarios? FD: no vendor has a perfect implementation. Failure detection is a safety net. Yoav Nir (relayed by Jabber scribe): My view may be colored by my own implementation, but we use the same implementation for site-to-site or remote access GW. It's easier to implement both sides as both maker and taker. In any case, the original initiator isn't necessary the token maker. PH: Tero, for this item, say "which scenarios you feel are important" rather than it's not good for some cases. Tero: I have sent 100s of lines of text earlier, and I have explained that. My implementation can do this using existing IKEv2 methods and it might be one half-trip faster. FD: we agree either side can rebuild the tunnel. But when you're traffic triggered (which is common), the traffic pattern may not be symmetric. TK: and I have explained how this can be dealt with using standard IKEv2 methods. PH: Tero, when you repost, specify which scenarios you are dealing with. FD: we should say in the doc that we want a “one size fit all scenario”, where end users don't need to be involved in configuring it. The issue remains open. We need to analyze it per use case. Issue 199: Section 7.4 is mostly wrong. TK: I don't think we need the whole section 7 any more. PH: It would be important to show people 5 years down the road why we did this. Issue 200: Section 8 ignores IKEv2 text. FD: the picture is also incorrect. Issue 201: Interdomain Gateways do not need QCD at all FD: this should be merged with 198. We should have a “one size fit all” solution, and independent of the traffic going inside the tunnel. Issue 202: Token makers generating the same tokens w/out sync DB TK: (Slide 15) MITM is much more powerful attack. This only requires a passive listener. The attacker doesn't even need to capture the gateway's reply. FD: MITM is wrong term, I agree. But even this type of attacker can do more dangerous things (TK disagrees, FD promises to expand on the mailing list). Dan Harkins: I don't see why this is a problem. It's a case with a cluster of nodes in standby. This is a stateful protocol, they're sharing state, there's no need to do QCD? And if you're not sharing state, why share the QCD token? FD: You're right, if they share state there's no need for QCD. The thing we see more and more is that synchronizing the SAs between gateways in hw appliances is expensive. DH: My point is that if you're not sharing state, don't share the QCD token. It's causing problems by sharing it. TK: They assume that the client will cache them and they can recover, using session resumption. Pratima Sethi: Sharing the QCD token helps you recover faster without synchronization. Faster than rebooting. PH: I'll restate (slide 14): Active/Standby are only sharing QCD secrets because its easier than sharing the whole state. Not the traditional HA, a QCD sharing scenario. FD: we offer a tradeoff compared to the universal failure detection provided by the liveness test. Speed of recovery vs. false positives. Yoav: It makes sense for a hot standby case without sharing, you want the failure to look like a really fast reboot. We should prevent the standby gateway from replying. It's dangerous for load-sharing. Gregory Lebowitz: It's not just dangerous, the load sharing case simply won't work. They'd have separate IP addresses. TK: the document already says that all cluster members should know whether an IKE SA is active. Other solutions don't work. FD: gateways even don't know if another gateway is up. Ahmad Muhanna: does a gateway know if it's in standby mode? FD: not in all scenarios. Not in anycast scenarios. PH: this contradicts the current text in the document. Some discussion was had about what really is active-standby definition. Yaron Sheffer (relayed by Jabber scribe): Should not reopen the IKE threat model. IKE is resistant to active MITM. Steve Kent: If it's really a standby it doesn't get traffic. Let's use the correct terminology. FD: the device is “standby” with respect to that particular peer. Maybe change the terminology. Devices may not know if they are active for a specific peer at any given time. Proposes a solution: the client should not accept a QCD token where its state machine indicates none should be coming. TK: an attacker can modify an (unauthenticated) ESP packet to cause the gateway to eventually respond with a token. FD: this requires a liveness test that will take care of the situation. PH: we should decide first whether we want to expand the doc's coverage. We should split #202 into 2-3 issues. High availability protocol open issues - 45 min - Dacheng Zhang After an HA event, the new active node might not have the most recent information (e.g., IPsec replay counters). PH: This HA proposal is only "tight" IPsec clusters, unlike the discussion about QCD. (slide 4) One solution is for the new active standby to request the newest information from the peer using an IKE notify. Delta in replay counter is sent, not the new value. Steve Kent: Pick the largest one, and send that in response? Paul: Yes, although might need to be more explicit. [Later note: this part was misunderstood by several people during the discussion – YS]. IKEv2 peers also need to negotiate the ability. Issue 1: Multiple failover Issue 2: How to synchronize the failover counter amongst different cluster members PH: These issues are about when there are 3 or more, and 2 go down. TK: I noticed that on slide 8 there is a problem, the ESN bit is overlapping the Critical bit. Needs to move elsewhere. Paul: Those who read the draft, did we close out the known issues from the last drafts? Does it match the req'ts document? Does anyone feel that we're not? (no response) Does anyone have any open issues? (None) We might go to WGLC on this sooner than QCD. FD: make sure ESP packets are not accepted while there is a replay “window of opportunity”. PH: this should at least go into the security considerations. IKEv2 Re-authentication PH: Keith Welter wanted this to be discussed and he's not here. There are some reauth issues with IKEv2bis, and there are some possible solutions. We might look at different reauth methods in the future, in a faster way. TK: I think we talked about this, we have an RFC out there talking about reauth. Are we coming back to that? PH: We said last time we don't want to over-complicate the base IKEv2 spec. TK: Adds complexity even if a separate RFC. PH: Now he's asking, is the problem big enough and we can do something less complicated? I'm not a big believer in this problem: if you do reauth, it's going to take some time. You don't want to over-optimize. But other people differ in opinion. Yoav: the idea is to keep the SAs up during reauth. IKEv2-- (IKEv2 "minus minus") Tero Kivinen Defining the minimal set of features that an IKE implementation needs to have. Lots of people discussing that IKEv2 is too complicated, other IETF groups (e.g. CORE) wanting to use IPsec but not the full IKEv2 functionality. They have constrained devices. There's lots of optional stuff in IKEv2. Explain that you only need 4 packets if you only need one SA. I started to take the IKEv2 docs and cut out stuff, and I ended up with 6-7 pages base spec plus 20 pages of payload description. All MUSTs except the one requiring support of certificates. PH: If you're willing to push together a rush draft, there's a couple of groups that might be interested in that. This will probably not be a WG document. Sean Turner: If you copy-and-paste the stuff out of the IKEv2 draft it might end up as pain due to errata having to be duplicated. You want to keep a pointer to the original. Also there's potential copyright issues. TK: I also added some new text. FD: even in IKEv1 we are seeing too minimal implementations. So this is useful as an introduction. The doc should be seen as a stepping stone towards a full implementation. Yaron: if this goes standards track, we will have a hard time synchronizing with the base spec. PH: informational. There was a discussion that this should be a profile kind of document, Informational, describing what would minimally be needed to implement IKEv2. The only issue is certificate support being a MUST. Yoav: this finally documents the mythical RFC 5996 “minimal implementation”. IKEv2 with CGA Jean-MIchel Combes Slides: http://www.ietf.org/proceedings/79/slides/ipsecme-3.pdf PH: Are any of these drawbacks different than CGA in general? J-M: Some are specific to IPsec. PH: What about the hard-coded algorithms? Steve Kent; the CSI WG talked about hard-coded algorithms but never did anything about them. The threat model is different. CGAs were intended to be "very local" -- used between a host and 1st hop gateway. When you move it here there's a different set of concerns. CGAs represent a "here's another way of doing autoconfig. and have a certain continuity" but it's for local uses. One of the features of IPv6 addresses were address generation for privacy reasons, and using multiple addresses concurrently. If you talk about CGAs as a static thing and beyond that local net, we're violating that other feature's trust model and that's a bad thing. J-M: there is a a MIP6 RFC (RFC 4866) on using CGAs to secure MIP6 signaling. (Ahmad: route optimization, not general MIP6). PH: This is for information now, and you'll let us know if you plan to progress it? J-M: Yes. Sean: apologizes for having held the PAKE proposals. We have 3 proposals. Will have an independent reviewer go through them in the next few weeks and will then decide how to proceed. Paul: please re-read the active drafts. We are still making protocol changes. From rsjenwar@gmail.com Thu Nov 18 08:50:26 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1813A688C for ; Thu, 18 Nov 2010 08:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3bF5arbvQb5 for ; Thu, 18 Nov 2010 08:50:24 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 786713A688B for ; Thu, 18 Nov 2010 08:50:24 -0800 (PST) Received: by wwa36 with SMTP id 36so3429025wwa.13 for ; Thu, 18 Nov 2010 08:51:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=GE+ORmpBLSgZ4nsw3mIIUmxwTayXwCUx8zAW++FKpnA=; b=Kdcke4PiEd+Fa5pWT3oyWowl1fIiAkpOLPV62zV3uOE0m08lbU0TYi9uso6kSKTFxR s5dO8spKQ16jVjK6U4aBdKhsXbkZdTrEGa0AN10LyeSQ6LuLsk3L0v1W3W4iMODQj+wP m9zF2D7KsQGMnis4p0MZ8NVJPcXgyJ5E4ZVss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=V2ZtAPZLUzrNkJMLlGZSVTLdslJF4QRyZkM/bwx80J95rKaLnhdkPBQ+CCfZIAW+Oo qXl0OkZXB+gis63CZD/g7dJo8yPQrZc2KS1k/aIc9Pi1nY21xYD+3Eg+ymPxcca5kb2+ C6vVXE7JIC/hmJ7z+B/8E1aGTVIQU7fJ8OgxA= MIME-Version: 1.0 Received: by 10.227.155.11 with SMTP id q11mr913398wbw.130.1290099071450; Thu, 18 Nov 2010 08:51:11 -0800 (PST) Received: by 10.227.62.205 with HTTP; Thu, 18 Nov 2010 08:51:11 -0800 (PST) In-Reply-To: <19674.32650.588044.52254@fireball.kivinen.iki.fi> References: <19674.32650.588044.52254@fireball.kivinen.iki.fi> Date: Thu, 18 Nov 2010 22:21:11 +0530 Message-ID: From: Raj Singh To: Tero Kivinen Content-Type: multipart/alternative; boundary=0016365ee562e1087c0495569816 Cc: ipsec Subject: Re: [IPsec] draft-ietf-ipsecme-ipsecha-protocol-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: RSJenwar@gmail.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 16:50:26 -0000 --0016365ee562e1087c0495569816 Content-Type: text/plain; charset=UTF-8 Hi Tero, Thanks for the comments. Opened Ticket #204 for format error in notification payload. Regarding the second issue. Some clarification is needed: The text meant that the message containing IKEV2_MESSAGE_ID_SYNC notification is allowed with message id zero only. This doesn't mean that message id is NOT allowed for other messages. Also, Yaron has suggested another method IKEv2 Message Id sync in another thread, after discussion further decision will be taken on this. Thanks, Raj On Wed, Nov 10, 2010 at 4:48 PM, Tero Kivinen wrote: > I haven't had time to read the draft-ietf-ipsecme-ipsecha-protocol-02 > completely yet, but while looking at the slides in the WG meeting, I > noticed one serious problem. > > The IKEV2_MESSAGE_ID_SYNC and IPSEC_REPLAY_COUNTER_SYNC messages do > not follow Notification payload syntax. > > For the IKEV2_MESSAGE_ID_SYNC there is only the missing critical bit: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Payload | RESERVED | Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > > instead of: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Payload |C| RESERVED | Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > For the IPSEC_REPLAY_COUNTER_SYNC it is bit more serious as it puts > something else on the same plaCe where the C bit normally is: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Payload |E| RESERVED | Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > I.e it adds "ESN bit" on the generic IKEv2 header in the location > where normally there is the critical bit. > > There is not really any need for the ESN bit as the length of the > delta value can be seen from the payload length field. > > ---------------------------------------------------------------------- > > Also the section 7 says: > > The Message ID value used in the Informational exchange that contains > the IKEV2_MESSAGE_ID_SYNC notification MUST be zero so that it is not > validated upon receipt as required by normal IKEv2 windowing. The > Message ID zero MUST be accepted only in an Informational exchange > that contains a notification of type IKEV2_MESSAGE_ID_SYNC. If any > Informational exchange has a Message ID zero, but not this > notification type, such messages MUST be discarded upon decryption > and the INVALID_SYNTAX notification SHOULD be sent. Other payloads > MUST NOT be sent in this Informational exchange. Whenever an > IKEV2_MESSAGE_ID_SYNC or IPSEC_REPLAY_COUNTER_SYNC notification > payload is received with an invalid failover count or invalid nonce > data, the event SHOULD be logged. > > Message ID zero is completely valid and legal value for message ID and > this text suddenly makes it impossible to use it anymore. The first > message responder ever always has Message ID zero, which means that if > you follow this then first message sent by responder will be rejected. > Message ID is also zero after IKE SA rekey. Also INVALID_SYNTAX > notification do have some special meaning in RFC5996: > > Only authentication failures (AUTHENTICATION_FAILED and EAP failure) > and malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE > SA without requiring an explicit INFORMATIONAL exchange carrying a > Delete payload. > .... > If a peer parsing a request notices that it is badly formatted (after > it has passed the message authentication code checks and window > checks) and it returns an INVALID_SYNTAX notification, then this > error notification is considered fatal in both peers, meaning that > the IKE SA is deleted without needing an explicit Delete payload. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --0016365ee562e1087c0495569816 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tero,

Thanks for the comments.
Opened Ticket #204 for format e= rror in notification payload.

Regarding the second issue. Some clari= fication is needed:
The text meant that the message containing IKEV2_MES= SAGE_ID_SYNC notification is allowed with message id zero only.
This doesn't mean that message id is NOT allowed for other messages.
Also, Yaron has suggested another method IKEv2 Message Id sync in anot= her thread, after discussion further decision will be taken on this.

Thanks,
Raj


On Wed, Nov 10, 2010 at 4:48 PM, Tero Ki= vinen <kivinen@iki.f= i> wrote:
I haven't had time to read the draft-ietf-ipsecme-ipsecha-protocol-02 completely yet, but while looking at the slides in the WG meeting, I
noticed one serious problem.

The IKEV2_MESSAGE_ID_SYNC and IPSEC_REPLAY_COUNTER_SYNC messages do
not follow Notification payload syntax.

For the IKEV2_MESSAGE_ID_SYNC there is only the missing critical bit:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A01 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0= 1
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =C2=A0 | Next Payload =C2=A0| =C2=A0 =C2=A0RESERVED =C2=A0 | =C2=A0 =C2=A0= =C2=A0 =C2=A0 Payload Length =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

instead of:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A01 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0= 1
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =C2=A0 | Next Payload =C2=A0|C| =C2=A0RESERVED =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Payload Length =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For the IPSEC_REPLAY_COUNTER_SYNC it is bit more serious as it puts
something else on the same plaCe where the C bit normally is:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A01 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
=C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0= 1
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =C2=A0 | Next Payload =C2=A0|E| RESERVED =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Payload Length =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I.e it adds "ESN bit" on the generic IKEv2 header in the location=
where normally there is the critical bit.

There is not really any need for the ESN bit as the length of the
delta value can be seen from the payload length field.

----------------------------------------------------------------------

Also the section 7 says:

=C2=A0 The Message ID value used in the Informational exchange that contai= ns
=C2=A0 the IKEV2_MESSAGE_ID_SYNC notification MUST be zero so that it is n= ot
=C2=A0 validated upon receipt as required by normal IKEv2 windowing. =C2= =A0The
=C2=A0 Message ID zero MUST be accepted only in an Informational exchange<= br> =C2=A0 that contains a notification of type IKEV2_MESSAGE_ID_SYNC. =C2=A0I= f any
=C2=A0 Informational exchange has a Message ID zero, but not this
=C2=A0 notification type, such messages MUST be discarded upon decryption<= br> =C2=A0 and the INVALID_SYNTAX notification SHOULD be sent. =C2=A0Other pay= loads
=C2=A0 MUST NOT be sent in this Informational exchange. =C2=A0Whenever an<= br> =C2=A0 IKEV2_MESSAGE_ID_SYNC or IPSEC_REPLAY_COUNTER_SYNC notification
=C2=A0 payload is received with an invalid failover count or invalid nonce=
=C2=A0 data, the event SHOULD be logged.

Message ID zero is completely valid and legal value for message ID and
this text suddenly makes it impossible to use it anymore. The first
message responder ever always has Message ID zero, which means that if
you follow this then first message sent by responder will be rejected.
Message ID is also zero after IKE SA rekey. Also INVALID_SYNTAX
notification do have some special meaning in RFC5996:

=C2=A0 Only authentication failures (AUTHENTICATION_FAILED and EAP failure= )
=C2=A0 and malformed messages (INVALID_SYNTAX) lead to a deletion of the I= KE
=C2=A0 SA without requiring an explicit INFORMATIONAL exchange carrying a<= br> =C2=A0 Delete payload.
....
=C2=A0 If a peer parsing a request notices that it is badly formatted (aft= er
=C2=A0 it has passed the message authentication code checks and window
=C2=A0 checks) and it returns an INVALID_SYNTAX notification, then this =C2=A0 error notification is considered fatal in both peers, meaning that<= br> =C2=A0 the IKE SA is deleted without needing an explicit Delete payload. --
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--0016365ee562e1087c0495569816-- From rsjenwar@gmail.com Thu Nov 18 08:53:47 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F39443A688C for ; Thu, 18 Nov 2010 08:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJG4-DzaAvMg for ; Thu, 18 Nov 2010 08:53:46 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id A7DE23A688B for ; Thu, 18 Nov 2010 08:53:45 -0800 (PST) Received: by wwa36 with SMTP id 36so3432395wwa.13 for ; Thu, 18 Nov 2010 08:54:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=1hob/yJJGjkZyc8EpKCxmrl55chNv7PaowgQQzJLgRc=; b=Rpv8T/foCb/SozP0NfOdtS5LZ4eOzKyaytNzjYjx9FOxcVeVCtVEbGDFgAZ6dWtoPs URFzkgEt2PqygWMijPwfTtWlt7WRXS0dO3jsb2UQpjCt3ndW9Em3BSw3lyt3BHRQAT2m tEfW0mz/88F9v184FE5ZnZm/F2CbdH/S9hAyw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=ic3rZFyjoB6G0P7G4RulbWVfgLmBJOdGsQvpdg5b2TRaITzQvlZn0XMFfhaBLqAOVg hYn/Yq8vxmOU4tz9rkGMVw+5Ni2ReL77RKZOgw2IykES2nbN+pw+kc+Vr1oz6voTyzuD OJ3thsDZKdJjxyS0AQifWFIxTJoGQBvBg5fHY= MIME-Version: 1.0 Received: by 10.227.155.11 with SMTP id q11mr917750wbw.130.1290099271980; Thu, 18 Nov 2010 08:54:31 -0800 (PST) Received: by 10.227.62.205 with HTTP; Thu, 18 Nov 2010 08:54:31 -0800 (PST) In-Reply-To: <4CDC08CF.8030106@gmail.com> References: <4CDC08CF.8030106@gmail.com> Date: Thu, 18 Nov 2010 22:24:31 +0530 Message-ID: From: Raj Singh To: Yaron Sheffer Content-Type: multipart/alternative; boundary=0016365ee562d4dafe049556a4d3 Cc: IPsecme WG Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: RSJenwar@gmail.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 16:53:47 -0000 --0016365ee562d4dafe049556a4d3 Content-Type: text/plain; charset=UTF-8 Hi Yaron, Thanks for the comments, Ticket#205 create to track this. On Thu, Nov 11, 2010 at 8:46 PM, Yaron Sheffer wrote: > Hi, > > it seems to me we have created an overly complicated solution for replay > protection of the Msg ID = 0 messages. Specifically, I think both the > failover counter and the nonce can be eliminated. > > Since the messages are protected under the IKE SA, we just need to ensure > that in a correct run of the protocol, there is never any need to repeat > previous messages. This can be done by including *both* Msg ID counters in > each message, and specifying a few rules to make sure counters never go > backwards. > > Cluster member to client: > - The counter I plan to use next (based on a traffic/rekey rate estimate, > must be higher than the last message that was actually sent, otherwise it > might be rejected) > It will be better to jump this counter by IKEv2 Message Send Window size rather than measuring or guessing traffic here. > - The counter I think you will use next (the last known value, as received > from the failed cluster member) > > Client to cluster: > - The counter I really plan to use next (must be equal to or higher than > the received value) > - The counter you said you will use next > > And each side must accept incoming messages only if both values are equal > to or larger than the corresponding one previously received from the same > peer, and one of them is strictly larger than the previous value. > > Am I missing anything? > > Thanks, > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --0016365ee562d4dafe049556a4d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yaron,

Thanks for the comments, Ticket#205 create to track this.<= br>
On Thu, Nov 11, 2010 at 8:46 PM, Yaron Sh= effer <yaronf.ietf@gmail.com> wrote:
Hi,

it seems to me we have created an overly complicated solution for replay pr= otection of the Msg ID =3D 0 messages. Specifically, I think both the failo= ver counter and the nonce can be eliminated.

Since the messages are protected under the IKE SA, we just need to ensure t= hat in a correct run of the protocol, there is never any need to repeat pre= vious messages. This can be done by including *both* Msg ID counters in eac= h message, and specifying a few rules to make sure counters never go backwa= rds.

Cluster member to client:
- The counter I plan to use next (based on a traffic/rekey rate estimate, m= ust be higher than the last message that was actually sent, otherwise it mi= ght be rejected)
=C2=A0
It will be better to= jump this counter by IKEv2 Message Send Window size rather than measuring = or guessing traffic here.
=C2=A0
- The counter I think you will use next (the last known value, as received = from the failed cluster member)

Client to cluster:
- The counter I really plan to use next (must be equal to or higher than th= e received value)
- The counter you said you will use next

And each side must accept incoming messages only if both values are equal t= o or larger than the corresponding one previously received from the same pe= er, and one of them is strictly larger than the previous value.

Am I missing anything?

Thanks,
=C2=A0 =C2=A0Yaron
_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--0016365ee562d4dafe049556a4d3-- From priikone@iki.fi Thu Nov 18 21:29:31 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B941628C0D9 for ; Thu, 18 Nov 2010 21:29:31 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rc0ssmwKkA-7 for ; Thu, 18 Nov 2010 21:29:31 -0800 (PST) Received: from otaku.Xtrmntr.org (sauna.silcnet.org [IPv6:2001:4118:10:4000::2205]) by core3.amsl.com (Postfix) with ESMTP id 9D45128C0FA for ; Thu, 18 Nov 2010 21:29:30 -0800 (PST) Received: by otaku.Xtrmntr.org (Postfix, from userid 201) id 4715B48AE; Fri, 19 Nov 2010 06:32:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by otaku.Xtrmntr.org (Postfix) with ESMTP id 391D348AB; Fri, 19 Nov 2010 06:32:21 +0100 (CET) Date: Fri, 19 Nov 2010 06:32:19 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: Raj Singh In-Reply-To: Message-ID: References: <4CDC08CF.8030106@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: IPsecme WG Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 05:29:31 -0000 On Thu, 18 Nov 2010, Raj Singh wrote: : > Cluster member to client: : > - The counter I plan to use next (based on a traffic/rekey rate estimate, : > must be higher than the last message that was actually sent, otherwise it : > might be rejected) : > : : It will be better to jump this counter by IKEv2 Message Send Window size : rather than measuring or guessing traffic here. : I think this isn't enough. The failover may have happened after node sent the packet but before the message id has been synced to another node (or sync was dropped, or whatever). Skipping window size (for example 1) may not be enough here. The remote peer is already processing the request with the message id and now we would be re-using the same message id. I also don't like that we'd have to guess the message id. : > - The counter I think you will use next (the last known value, as received : > from the failed cluster member) : > : > Client to cluster: : > - The counter I really plan to use next (must be equal to or higher than : > the received value) : > - The counter you said you will use next : > I think it's important that the peer that actually knows my message id tells it to me. IMO, this can work only we're allowed to freely select the next message ID I'm going to use. Ie. skip as much as I want to skip, same way as we can skip ESP sequence numbers. Pekka From yaronf.ietf@gmail.com Thu Nov 18 22:50:00 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22EFC3A67F9 for ; Thu, 18 Nov 2010 22:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.404 X-Spam-Level: X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiicyDpPFLg4 for ; Thu, 18 Nov 2010 22:49:59 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id F3ED33A6407 for ; Thu, 18 Nov 2010 22:49:58 -0800 (PST) Received: by wyb29 with SMTP id 29so4076508wyb.31 for ; Thu, 18 Nov 2010 22:50:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=O9B0Kvc86WEefMm5HLigH4jdAsCce7gA5rSYb7U3Bds=; b=TWA0roWK3XoDcIrOramD1Mh4bklEhyganruzUO8Pj/78V4ZNIafQX6TQ5DGUVxEpLI mCCPrgB95KhQso/rbHcukMQCl432gTSBqQaQL7xxos2DC0o5VbZEGov37KDU4mn63IIc HtjRYtP3q6Qr4coNz8uhg6VqPEBhvJwhTL6Zc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ronZeMP68Y+JO6jeuo8d84FqCbITTfvt+UIDqPTZHHgyPNGBR54Lw1D3yknQU/Fnx4 kDegPLB/3kRxGnugjqHvF2m8KMiWktDpgxettrfaVnCLq05hCAeURiRBsWCh4+0nt0yH Sba1T4JtQJoByPbkqiC6DTEIr/xtCgavmM2SU= Received: by 10.227.143.205 with SMTP id w13mr1760605wbu.99.1290149447357; Thu, 18 Nov 2010 22:50:47 -0800 (PST) Received: from [10.0.0.1] (bzq-79-181-24-102.red.bezeqint.net [79.181.24.102]) by mx.google.com with ESMTPS id b30sm849213wbb.16.2010.11.18.22.50.45 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Nov 2010 22:50:46 -0800 (PST) Message-ID: <4CE61E43.9080609@gmail.com> Date: Fri, 19 Nov 2010 08:50:43 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Pekka Riikonen References: <4CDC08CF.8030106@gmail.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Raj Singh Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 06:50:00 -0000 Yes, in order to avoid replay issues, each side should be able to skip forward as much as it wants to. Thanks, Yaron On 11/19/2010 07:32 AM, Pekka Riikonen wrote: > On Thu, 18 Nov 2010, Raj Singh wrote: > > :> Cluster member to client: > :> - The counter I plan to use next (based on a traffic/rekey rate estimate, > :> must be higher than the last message that was actually sent, otherwise it > :> might be rejected) > :> > : > : It will be better to jump this counter by IKEv2 Message Send Window size > : rather than measuring or guessing traffic here. > : > I think this isn't enough. The failover may have happened after node sent > the packet but before the message id has been synced to another node (or > sync was dropped, or whatever). Skipping window size (for example 1) may > not be enough here. The remote peer is already processing the request > with the message id and now we would be re-using the same message id. > > I also don't like that we'd have to guess the message id. > > :> - The counter I think you will use next (the last known value, as received > :> from the failed cluster member) > :> > :> Client to cluster: > :> - The counter I really plan to use next (must be equal to or higher than > :> the received value) > :> - The counter you said you will use next > :> > I think it's important that the peer that actually knows my message id > tells it to me. > > IMO, this can work only we're allowed to freely select the next message ID > I'm going to use. Ie. skip as much as I want to skip, same way as we can > skip ESP sequence numbers. > > Pekka From kivinen@iki.fi Fri Nov 19 03:37:19 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855E73A6902 for ; Fri, 19 Nov 2010 03:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fpF4KdNxKhr for ; Fri, 19 Nov 2010 03:37:18 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 299153A68FE for ; Fri, 19 Nov 2010 03:37:17 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id oAJBc1X4015436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Nov 2010 13:38:01 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id oAJBc17u004787; Fri, 19 Nov 2010 13:38: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: <19686.24984.949221.628414@fireball.kivinen.iki.fi> Date: Fri, 19 Nov 2010 13:38:00 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <4CDC08CF.8030106@gmail.com> References: <4CDC08CF.8030106@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 10 min Cc: IPsecme WG Subject: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 11:37:19 -0000 Yaron Sheffer writes: > it seems to me we have created an overly complicated solution for replay > protection of the Msg ID = 0 messages. Specifically, I think both the > failover counter and the nonce can be eliminated. > > Since the messages are protected under the IKE SA, we just need to > ensure that in a correct run of the protocol, there is never any need to > repeat previous messages. This can be done by including *both* Msg ID > counters in each message, and specifying a few rules to make sure > counters never go backwards. > > Cluster member to client: > - The counter I plan to use next (based on a traffic/rekey rate > estimate, must be higher than the last message that was actually sent, > otherwise it might be rejected) > - The counter I think you will use next (the last known value, as > received from the failed cluster member) > > Client to cluster: > - The counter I really plan to use next (must be equal to or higher than > the received value) > - The counter you said you will use next > > And each side must accept incoming messages only if both values are > equal to or larger than the corresponding one previously received from > the same peer, and one of them is strictly larger than the previous value. Why not just take max of both counters. I.e. cluster member sends following counters: - host_a_out_id = Message ID I plan to use next (i.e. last message id + 1) - host_a_in_id = Largest Message ID I have received from you Then the client has host_b_out_id (Message ID client plans to use next (i.e. last message id + 1), and host_b_in_id (Largest message ID he has seen from the cluster members) and will send: - max(host_a_out_id, host_b_in_id) - max(host_a_in_id, host_b_out_id) In normal case host_a_out_id and host_b_in_id are same, but if failed host a cluster member has sent message which never reached the client before crash, but did reach failover cluster member in sync message the host_a_out_id might be larger than host_b_in_id, and if failed cluster member has done exchange with client which didn't reach the failover cluster member then host_b_in_id might be bigger than host_a_out_id. The host_a_in_id should always be smaller than or equal to host_b_out_id as host B do have authorative knowledge about the message ID (host A might have missed some messages). If there is failover situation in both ends (i.e both ends fail simultaneously) then the host_b_out_id might be smaller than host_a_in_id, and sending max value of those two will solve even that case. Now the real question is what are we going to do with the exchanges which are still in progress when the sync message is received, and how do we recover when we notice that we do have missed IKE messages, meaning we have created, rekeyed or deleted some Child SA in those messages we lost because of failover. -- kivinen@iki.fi From kivinen@iki.fi Fri Nov 19 03:50:41 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90EF28C0E7 for ; Fri, 19 Nov 2010 03:50:41 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-yJ1lWDasIf for ; Fri, 19 Nov 2010 03:50:40 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 79AFF28C0DC for ; Fri, 19 Nov 2010 03:50:40 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id oAJBpSJZ001042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Nov 2010 13:51:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id oAJBpSiu004833; Fri, 19 Nov 2010 13:51:28 +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: <19686.25792.78130.322186@fireball.kivinen.iki.fi> Date: Fri, 19 Nov 2010 13:51:28 +0200 From: Tero Kivinen To: Pekka Riikonen In-Reply-To: References: <4CDC08CF.8030106@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: IPsecme WG , Raj Singh Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 11:50:41 -0000 Pekka Riikonen writes: > On Thu, 18 Nov 2010, Raj Singh wrote: > > : > Cluster member to client: > : > - The counter I plan to use next (based on a traffic/rekey rate estimate, > : > must be higher than the last message that was actually sent, otherwise it > : > might be rejected) > : > > : > : It will be better to jump this counter by IKEv2 Message Send Window size > : rather than measuring or guessing traffic here. > : > I think this isn't enough. The failover may have happened after node sent > the packet but before the message id has been synced to another node (or > sync was dropped, or whatever). Skipping window size (for example 1) may > not be enough here. The remote peer is already processing the request > with the message id and now we would be re-using the same message id. > > I also don't like that we'd have to guess the message id. Missed that guess part in the original message. I do not think there is any way to guess how many messages there was, as in normal case it will be either 0 or 1 (there are not that many Child SA creations / rekeys / deletions, and sane implementations do not do periodical liveness checks). On the other hand if we take max of the value what sender and receiver things the mssage ID for that direction should be that will give us value which can be used from that point on, so no need to guess. > IMO, this can work only we're allowed to freely select the next message ID > I'm going to use. Ie. skip as much as I want to skip, same way as we can > skip ESP sequence numbers. During the failover you will be skipping over the message IDs the other end has seen, but which you do not know you have sent if we are using the max of message ID method. -- kivinen@iki.fi From yaronf.ietf@gmail.com Fri Nov 19 03:50:43 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA0828C0E8 for ; Fri, 19 Nov 2010 03:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.417 X-Spam-Level: X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlgal93ji7+a for ; Fri, 19 Nov 2010 03:50:43 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id A663328C0DC for ; Fri, 19 Nov 2010 03:50:42 -0800 (PST) Received: by wyb29 with SMTP id 29so4329396wyb.31 for ; Fri, 19 Nov 2010 03:51:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=lqQO5V4qieruVqwOWUFOB/WB40zwDRtbqc3IN0PhPXg=; b=ne4RHj8tJs0jHYqHa9+JCcTY1nEiawcyWPmuSLeXGAYVlPZY2qTLwWP/BgoOm1Mjmr XaFYzN6SIUH+dyrT2Dvi4NdfEjGv2M5Z9L/bkumdEQkZgPzdb1lDqRA6gFzUBAecE6hw cy49XHr/Y4z3BcJwv4h3A78XIup261ohmgo2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=BxH2HqSHhlTmFayrf33/Y6e9CLMBIrdzuZ/zirThGDh+aGLr1iMOwBT2CBw3my1tLw D+7y6sxom6+DhIrX/cb7oudY6hcLy6pEx4LkG7vplUy7CUjK4p+9L6T6qa3puJYNzfBV apJIZotMxROOcuqxMq3vBz3buMyniXazJq6VY= Received: by 10.227.157.196 with SMTP id c4mr2115579wbx.174.1290167491112; Fri, 19 Nov 2010 03:51:31 -0800 (PST) Received: from [10.0.0.1] (bzq-79-181-24-102.red.bezeqint.net [79.181.24.102]) by mx.google.com with ESMTPS id h29sm1024744wbc.9.2010.11.19.03.51.27 (version=SSLv3 cipher=RC4-MD5); Fri, 19 Nov 2010 03:51:29 -0800 (PST) Message-ID: <4CE664BC.9090005@gmail.com> Date: Fri, 19 Nov 2010 13:51:24 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Tero Kivinen References: <4CDC08CF.8030106@gmail.com> <19686.24984.949221.628414@fireball.kivinen.iki.fi> In-Reply-To: <19686.24984.949221.628414@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 11:50:44 -0000 Hi Tero, one attractive way to deal with the hard problems is to ignore them :-) After resynching the IKE SA, the client looks at its active Child SAs. If any SA is recent (say, less than 1 minute old), it initiates CCSA for that SA. We could add protocol elements to query the peer regarding active SAs, but I don't think we want to go that way. Thanks, Yaron On 11/19/2010 01:38 PM, Tero Kivinen wrote: > Yaron Sheffer writes: >> it seems to me we have created an overly complicated solution for replay >> protection of the Msg ID = 0 messages. Specifically, I think both the >> failover counter and the nonce can be eliminated. >> >> Since the messages are protected under the IKE SA, we just need to >> ensure that in a correct run of the protocol, there is never any need to >> repeat previous messages. This can be done by including *both* Msg ID >> counters in each message, and specifying a few rules to make sure >> counters never go backwards. >> >> Cluster member to client: >> - The counter I plan to use next (based on a traffic/rekey rate >> estimate, must be higher than the last message that was actually sent, >> otherwise it might be rejected) >> - The counter I think you will use next (the last known value, as >> received from the failed cluster member) >> >> Client to cluster: >> - The counter I really plan to use next (must be equal to or higher than >> the received value) >> - The counter you said you will use next >> >> And each side must accept incoming messages only if both values are >> equal to or larger than the corresponding one previously received from >> the same peer, and one of them is strictly larger than the previous value. > > Why not just take max of both counters. I.e. cluster member sends > following counters: > > - host_a_out_id = Message ID I plan to use next (i.e. last > message id + 1) > - host_a_in_id = Largest Message ID I have received from you > > Then the client has host_b_out_id (Message ID client plans to use next > (i.e. last message id + 1), and host_b_in_id (Largest message ID he > has seen from the cluster members) and will send: > > - max(host_a_out_id, host_b_in_id) > - max(host_a_in_id, host_b_out_id) > > In normal case host_a_out_id and host_b_in_id are same, but if failed > host a cluster member has sent message which never reached the client > before crash, but did reach failover cluster member in sync message > the host_a_out_id might be larger than host_b_in_id, and if failed > cluster member has done exchange with client which didn't reach the > failover cluster member then host_b_in_id might be bigger than > host_a_out_id. > > The host_a_in_id should always be smaller than or equal to > host_b_out_id as host B do have authorative knowledge about the > message ID (host A might have missed some messages). If there is > failover situation in both ends (i.e both ends fail simultaneously) > then the host_b_out_id might be smaller than host_a_in_id, and sending > max value of those two will solve even that case. > > Now the real question is what are we going to do with the exchanges > which are still in progress when the sync message is received, and how > do we recover when we notice that we do have missed IKE messages, > meaning we have created, rekeyed or deleted some Child SA in those > messages we lost because of failover. From yaronf.ietf@gmail.com Fri Nov 19 03:59:12 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0EE03A682B for ; Fri, 19 Nov 2010 03:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhsg5rID6sR7 for ; Fri, 19 Nov 2010 03:59:12 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id BA0B728B56A for ; Fri, 19 Nov 2010 03:59:11 -0800 (PST) Received: by wwb17 with SMTP id 17so155709wwb.1 for ; Fri, 19 Nov 2010 04:00:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=c2WRWGkrELCnnPMihjvivYX5AI8uCWCab7XzthWD908=; b=hl6WPz04e39xWTQR5x+GObdpK/7/QAfOJxKlU+a7yyeYtbYt7fqwrEiHBj5FnmBGV3 Kq7Exc5TUpjJzcQ4e1yBcDntEwqJLSzmge9R6/mI1jJafWEZKT2BmqWEGr1li7W4RojR dzzBFwhe+sqnIx25UtyLybxjlfCFPoIUeeLEs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=x2jW9MCx+eQ6biNRDEWdf7IhsDWYvxugiQ2GCzH3SM7Lky16l72iw2UTWJznIHhc8X mrU/f1OWxGjLTXB9MDn3Nyt8NDvz7QphObeSqHztXHPBsH3iX425DXDtVxsWPqDJlnUU 8QGI9ADMqMhhRaCTuHmcHJnDQ649hcCLYRTl4= Received: by 10.227.155.11 with SMTP id q11mr2098551wbw.130.1290168000457; Fri, 19 Nov 2010 04:00:00 -0800 (PST) Received: from [10.0.0.1] (bzq-79-181-24-102.red.bezeqint.net [79.181.24.102]) by mx.google.com with ESMTPS id a17sm1030508wbe.6.2010.11.19.03.59.56 (version=SSLv3 cipher=RC4-MD5); Fri, 19 Nov 2010 03:59:59 -0800 (PST) Message-ID: <4CE666B9.5040302@gmail.com> Date: Fri, 19 Nov 2010 13:59:53 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Tero Kivinen References: <4CDC08CF.8030106@gmail.com> <19686.25792.78130.322186@fireball.kivinen.iki.fi> In-Reply-To: <19686.25792.78130.322186@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Pekka Riikonen , Raj Singh Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 11:59:12 -0000 Let's take the extreme case where the cluster and the peer synchronize the SA, then there is no IKE traffic, and then they synchronize the SA again. If we don't do anything special, the second pair of synch messages will be identical to the first, i.e. will look like a replay. So we have to prevent this case. One trivial solution is to mandate one liveness test (initiated by the peer) immediately after the synch. Thanks, Yaron On 11/19/2010 01:51 PM, Tero Kivinen wrote: > Pekka Riikonen writes: >> On Thu, 18 Nov 2010, Raj Singh wrote: >> >> :> Cluster member to client: >> :> - The counter I plan to use next (based on a traffic/rekey rate estimate, >> :> must be higher than the last message that was actually sent, otherwise it >> :> might be rejected) >> :> >> : >> : It will be better to jump this counter by IKEv2 Message Send Window size >> : rather than measuring or guessing traffic here. >> : >> I think this isn't enough. The failover may have happened after node sent >> the packet but before the message id has been synced to another node (or >> sync was dropped, or whatever). Skipping window size (for example 1) may >> not be enough here. The remote peer is already processing the request >> with the message id and now we would be re-using the same message id. >> >> I also don't like that we'd have to guess the message id. > > Missed that guess part in the original message. I do not think there > is any way to guess how many messages there was, as in normal case it > will be either 0 or 1 (there are not that many Child SA creations / > rekeys / deletions, and sane implementations do not do periodical > liveness checks). > > On the other hand if we take max of the value what sender and receiver > things the mssage ID for that direction should be that will give us > value which can be used from that point on, so no need to guess. > >> IMO, this can work only we're allowed to freely select the next message ID >> I'm going to use. Ie. skip as much as I want to skip, same way as we can >> skip ESP sequence numbers. > > During the failover you will be skipping over the message IDs the > other end has seen, but which you do not know you have sent if we are > using the max of message ID method. From priikone@iki.fi Sat Nov 20 04:06:17 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 591D03A69C0 for ; Sat, 20 Nov 2010 04:06:17 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9TaVPiXZbRP for ; Sat, 20 Nov 2010 04:06:15 -0800 (PST) Received: from otaku.Xtrmntr.org (sauna.silcnet.org [IPv6:2001:4118:10:4000::2205]) by core3.amsl.com (Postfix) with ESMTP id 254EA3A6910 for ; Sat, 20 Nov 2010 04:06:12 -0800 (PST) Received: by otaku.Xtrmntr.org (Postfix, from userid 201) id 7E0BA48AB; Sat, 20 Nov 2010 13:09:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by otaku.Xtrmntr.org (Postfix) with ESMTP id 7CA654880; Sat, 20 Nov 2010 13:09:08 +0100 (CET) Date: Sat, 20 Nov 2010 13:09:08 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: Tero Kivinen In-Reply-To: <19686.24984.949221.628414@fireball.kivinen.iki.fi> Message-ID: References: <4CDC08CF.8030106@gmail.com> <19686.24984.949221.628414@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: IPsecme WG Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 12:06:17 -0000 : Why not just take max of both counters. I.e. cluster member sends : following counters: : : - host_a_out_id = Message ID I plan to use next (i.e. last : message id + 1) : - host_a_in_id = Largest Message ID I have received from you : : Then the client has host_b_out_id (Message ID client plans to use next : (i.e. last message id + 1), and host_b_in_id (Largest message ID he : has seen from the cluster members) and will send: : : - max(host_a_out_id, host_b_in_id) : - max(host_a_in_id, host_b_out_id) : Isn't this what the -02 draft specifies? ... o The active member dies, and a standby member takes over. The standby member sends its own idea of the IKE Message IDs (both incoming and outgoing) to the peer in an Informational message exchange with Message ID zero. o The peer first authenticates the message and then validates the failover count. The peer compares the received values with the values available locally and picks the higher value. It then updates its Message IDs with the higher values and also propose the same values in its response. ... : Now the real question is what are we going to do with the exchanges : which are still in progress when the sync message is received, and how : do we recover when we notice that we do have missed IKE messages, : meaning we have created, rekeyed or deleted some Child SA in those : messages we lost because of failover. : Draft specifies what to do here as well, at least partly. Also note that you may never notice missed IKE messages because they happened in the failed cluster node. Normal crash recovery takes care of any desync problems that may have happened. ... o The peer should not wait for any pending responses while responding with the new Message ID values. For example, if the window size is 5 and the peer's window is 3-7, and if the peer has sent requests 3, 4, 5, 6, 7 and received responses only for 4, 5, 6, 7 but not for 3, then it should include the value 8 in its EXPECTED_SEND_REQ_MESSAGE_ID payload and should not wait for a response to message 3 anymore. o Similarly, the peer should also not wait for pending (incoming) requests. For example if the window size is 5 and the peer's window is 3-7 and if the peer has received requests 4, 5, 6, 7 but not 3, then it should send the value 8 in the EXPECTED_RECV_REQ_MESSAGE_ID payload, and should not expect to receive message 3 anymore. ... Are the Security Considerations in the draft valid anymore at all? And are the nonce and failover count needed? Yaron wanted to eliminate these, and I'm all for it. Pekka From priikone@iki.fi Sat Nov 20 04:11:16 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140B93A69CE for ; Sat, 20 Nov 2010 04:11:16 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMnScqi3G4jW for ; Sat, 20 Nov 2010 04:11:14 -0800 (PST) Received: from otaku.Xtrmntr.org (sauna.silcnet.org [IPv6:2001:4118:10:4000::2205]) by core3.amsl.com (Postfix) with ESMTP id 0E87E3A68FA for ; Sat, 20 Nov 2010 04:11:14 -0800 (PST) Received: by otaku.Xtrmntr.org (Postfix, from userid 201) id 8DF1D48AB; Sat, 20 Nov 2010 13:14:13 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by otaku.Xtrmntr.org (Postfix) with ESMTP id 88CE24880; Sat, 20 Nov 2010 13:14:13 +0100 (CET) Date: Sat, 20 Nov 2010 13:14:13 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: Yaron Sheffer In-Reply-To: <4CE666B9.5040302@gmail.com> Message-ID: References: <4CDC08CF.8030106@gmail.com> <19686.25792.78130.322186@fireball.kivinen.iki.fi> <4CE666B9.5040302@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: IPsecme WG , Tero Kivinen , Raj Singh Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 12:11:16 -0000 : : Let's take the extreme case where the cluster and the peer synchronize : the SA, then there is no IKE traffic, and then they synchronize the SA : again. If we don't do anything special, the second pair of synch : messages will be identical to the first, i.e. will look like a replay. : So we have to prevent this case. One trivial solution is to mandate one : liveness test (initiated by the peer) immediately after the synch. : Note that draft recommends that the sync is done only when the IKE SA is actually needed. If there is not IKE traffic then the sync would have never been done in the first place. ... Since there can be a large number of sessions at the standby member, and sending synchronization exchanges for all of them may result in overload, the standby member can choose to initiate the exchange in a "lazy" fashion: only when it has to send or receive the request. In general, the standby member is free to initiate this exchange at its discretion. ... I've implemented the lazy sync, it's seems the best way to do it. Pekka From yaronf.ietf@gmail.com Sat Nov 20 14:01:07 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DBAE28C11C for ; Sat, 20 Nov 2010 14:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7g6pMxBm4yAl for ; Sat, 20 Nov 2010 14:01:06 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 201DB28C111 for ; Sat, 20 Nov 2010 14:01:05 -0800 (PST) Received: by wwa36 with SMTP id 36so5800025wwa.13 for ; Sat, 20 Nov 2010 14:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=6EV/AX5KwTA85Wl9YUp9POFnrjz6J995QzRhYJJhRU0=; b=xZ3dNDg9/06Kwp9BuusZKT2QtSRTVUJoLTM5cEodJvO9bCr6lY7VXC2CgcZDXwFJtT dFh05U/bLe931gzFHCqOXkbE5TVzbmkkFfv/1U841tSexokPTDikcR+HXycayMPwEh5C L++JasbWQvTgQBYRKDvwbdZZ3Ni2RigRBxA/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=fWoZYIRSl13GyW4yfS8ug/dC2ZgRTIZ6ziLbv2VjqWb/OUjdscKVo9vOXAOC5tgUit mriR6uyHX1Py/oNrKRrHX7pcikIXreUd/SzySJg4k6KNJvTXEwfFWlrFEq0mgM87/BFx bgPzclBsGhxxPX+wR1zn3gH1jFe0Ov0+h5CrA= Received: by 10.227.132.143 with SMTP id b15mr4038759wbt.36.1290290517206; Sat, 20 Nov 2010 14:01:57 -0800 (PST) Received: from [10.0.0.1] (bzq-79-181-24-102.red.bezeqint.net [79.181.24.102]) by mx.google.com with ESMTPS id ga16sm2136385wbb.7.2010.11.20.14.01.50 (version=SSLv3 cipher=RC4-MD5); Sat, 20 Nov 2010 14:01:54 -0800 (PST) Message-ID: <4CE8454B.2000709@gmail.com> Date: Sun, 21 Nov 2010 00:01:47 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Pekka Riikonen References: <4CDC08CF.8030106@gmail.com> <19686.25792.78130.322186@fireball.kivinen.iki.fi> <4CE666B9.5040302@gmail.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Tero Kivinen , Raj Singh Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 22:01:07 -0000 Hi Pekka, the text you are quoting provides implementation guidance (probably good one), but does not "recommend" (in the RFC 2119 sense of the word, i.e. equivalent to a normative SHOULD) to do so. We should have stronger text if we are to avoid accidental replay. Thanks, Yaron On 11/20/2010 02:14 PM, Pekka Riikonen wrote: > > : > : Let's take the extreme case where the cluster and the peer synchronize > : the SA, then there is no IKE traffic, and then they synchronize the SA > : again. If we don't do anything special, the second pair of synch > : messages will be identical to the first, i.e. will look like a replay. > : So we have to prevent this case. One trivial solution is to mandate one > : liveness test (initiated by the peer) immediately after the synch. > : > Note that draft recommends that the sync is done only when the IKE SA is > actually needed. If there is not IKE traffic then the sync would have > never been done in the first place. > > ... > Since there can be a large number of sessions at the standby member, > and sending synchronization exchanges for all of them may result in > overload, the standby member can choose to initiate the exchange in a > "lazy" fashion: only when it has to send or receive the request. In > general, the standby member is free to initiate this exchange at its > discretion. > ... > > I've implemented the lazy sync, it's seems the best way to do it. > > Pekka From syedah@huawei.com Sun Nov 21 21:54:51 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39BA3A6A2C for ; Sun, 21 Nov 2010 21:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.894 X-Spam-Level: X-Spam-Status: No, score=-3.894 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8do4-1hK1Pse for ; Sun, 21 Nov 2010 21:54:44 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D46963A6952 for ; Sun, 21 Nov 2010 21:54:43 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC900C78V4GR9@szxga04-in.huawei.com> for ipsec@ietf.org; Mon, 22 Nov 2010 13:55:28 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC900BD7V4GOT@szxga04-in.huawei.com> for ipsec@ietf.org; Mon, 22 Nov 2010 13:55:28 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LC900KO9V4FHN@szxml06-in.huawei.com> for ipsec@ietf.org; Mon, 22 Nov 2010 13:55:28 +0800 (CST) Date: Mon, 22 Nov 2010 11:25:26 +0530 From: Syed Ajim Hussain In-reply-to: To: ipsec@ietf.org Message-id: <627E583314D94AF6B9E9CB08991E28BF@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_yak7KriqKw7LIAYY1cjAmQ)" Thread-index: AcuJtwz7riQL/yrbRqOq8wev+FnbKgAUIKUg References: Subject: [IPsec] Generating Keying Material for the IKE_SA (IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 05:54:51 -0000 This is a multi-part message in MIME format. --Boundary_(ID_yak7KriqKw7LIAYY1cjAmQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi All I have some doubt about Security of IKEv2 protocol. In the process Of generating Keys, every parameter is taken from IKE_SA_INIT Messages Which is un-unencrypted. If attacker using some tools capturing all the IKE Packets from network, he can easily generates the Keys. Although attacker can not establish a SA without proper configuration information, but still he can easily get the Keys, and he will be able to decrypt all the IKE Encrypted and IPSEC Encrypted packets. Don't you think this is a big Security Risk? In IKEv1 Pre-shared key auth, PSK was taken as part of key Calculation with is a secret to generate Key and provides some level of Security. IKE Key generation process: SKEYSEED = prf(Ni | Nr, g^ir) {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) With Regards Syed Ajim **************************************************************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! **************************************************************************** ________________________________ -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of ipsec-request@ietf.org Sent: Monday, November 22, 2010 1:30 AM To: ipsec@ietf.org Subject: IPsec Digest, Vol 79, Issue 11 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/ipsec Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send IPsec mailing list submissions to ipsec@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/ipsec or, via email, send a message with subject or body 'help' to ipsec-request@ietf.org You can reach the person managing the list at ipsec-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of IPsec digest..." Today's Topics: 1. Re: HA protocol replay protection (Yaron Sheffer) ---------------------------------------------------------------------- Message: 1 Date: Sun, 21 Nov 2010 00:01:47 +0200 From: Yaron Sheffer Subject: Re: [IPsec] HA protocol replay protection To: Pekka Riikonen Cc: IPsecme WG , Tero Kivinen , Raj Singh Message-ID: <4CE8454B.2000709@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Hi Pekka, the text you are quoting provides implementation guidance (probably good one), but does not "recommend" (in the RFC 2119 sense of the word, i.e. equivalent to a normative SHOULD) to do so. We should have stronger text if we are to avoid accidental replay. Thanks, Yaron On 11/20/2010 02:14 PM, Pekka Riikonen wrote: > > : > : Let's take the extreme case where the cluster and the peer synchronize > : the SA, then there is no IKE traffic, and then they synchronize the SA > : again. If we don't do anything special, the second pair of synch > : messages will be identical to the first, i.e. will look like a replay. > : So we have to prevent this case. One trivial solution is to mandate one > : liveness test (initiated by the peer) immediately after the synch. > : > Note that draft recommends that the sync is done only when the IKE SA is > actually needed. If there is not IKE traffic then the sync would have > never been done in the first place. > > ... > Since there can be a large number of sessions at the standby member, > and sending synchronization exchanges for all of them may result in > overload, the standby member can choose to initiate the exchange in a > "lazy" fashion: only when it has to send or receive the request. In > general, the standby member is free to initiate this exchange at its > discretion. > ... > > I've implemented the lazy sync, it's seems the best way to do it. > > Pekka ------------------------------ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec End of IPsec Digest, Vol 79, Issue 11 ************************************* --Boundary_(ID_yak7KriqKw7LIAYY1cjAmQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi All

   I have some doubt about Security of IKEv2 protocol.  In the process         

   Of generating Keys, every parameter is taken from IKE_SA_INIT Messages  

   Which is un-unencrypted.

 

   If attacker using some tools capturing all the IKE Packets from network,     

   he can easily generates the Keys.  Although attacker can not establish a  

   SA without proper configuration information, but still he can easily get

   the Keys, and he will be able to decrypt all  the  IKE Encrypted and  

   IPSEC Encrypted packets.    

 

   Don’t you think this is a big Security Risk? In IKEv1 Pre-shared key auth, PSK was taken as  part of key

   Calculation with is a secret to generate Key and provides some level of Security.  

 

   IKE Key generation process:

 

   SKEYSEED = prf(Ni | Nr, g^ir)

 

   {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+

                 (SKEYSEED, Ni | Nr | SPIi | SPIr )

 

With Regards

Syed Ajim

 

 

 

 

****************************************************************************

 

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

 

****************************************************************************

 

________________________________

 

 

 

 

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of ipsec-request@ietf.org
Sent: Monday, November 22, 2010 1:30 AM
To: ipsec@ietf.org
Subject: IPsec Digest, Vol 79, Issue 11

 

If you have received this digest without all the individual message

attachments you will need to update your digest options in your list

subscription.  To do so, go to

 

https://www.ietf.org/mailman/listinfo/ipsec

 

Click the 'Unsubscribe or edit options' button, log in, and set "Get

MIME or Plain Text Digests?" to MIME.  You can set this option

globally for all the list digests you receive at this point.

 

 

 

Send IPsec mailing list submissions to

      ipsec@ietf.org

 

To subscribe or unsubscribe via the World Wide Web, visit

      https://www.ietf.org/mailman/listinfo/ipsec

or, via email, send a message with subject or body 'help' to

      ipsec-request@ietf.org

 

You can reach the person managing the list at

      ipsec-owner@ietf.org

 

When replying, please edit your Subject line so it is more specific

than "Re: Contents of IPsec digest..."

 

 

Today's Topics:

 

   1. Re: HA protocol replay protection (Yaron Sheffer)

 

 

----------------------------------------------------------------------

 

Message: 1

Date: Sun, 21 Nov 2010 00:01:47 +0200

From: Yaron Sheffer <yaronf.ietf@gmail.com>

Subject: Re: [IPsec] HA protocol replay protection

To: Pekka Riikonen <priikone@iki.fi>

Cc: IPsecme WG <ipsec@ietf.org>, Tero Kivinen <kivinen@iki.fi>,   Raj

      Singh <rsjenwar@gmail.com>

Message-ID: <4CE8454B.2000709@gmail.com>

Content-Type: text/plain; charset=US-ASCII; format=flowed

 

Hi Pekka,

 

the text you are quoting provides implementation guidance (probably good

one), but does not "recommend" (in the RFC 2119 sense of the word, i.e.

equivalent to a normative SHOULD) to do so. We should have stronger text

if we are to avoid accidental replay.

 

Thanks,

      Yaron

 

On 11/20/2010 02:14 PM, Pekka Riikonen wrote:

> 

> :

> : Let's take the extreme case where the cluster and the peer synchronize

> : the SA, then there is no IKE traffic, and then they synchronize the SA

> : again. If we don't do anything special, the second pair of synch

> : messages will be identical to the first, i.e. will look like a replay.

> : So we have to prevent this case. One trivial solution is to mandate one

> : liveness test (initiated by the peer) immediately after the synch.

> :

> Note that draft recommends that the sync is done only when the IKE SA is

> actually needed.  If there is not IKE traffic then the sync would have

> never been done in the first place.

> 

> ...

>     Since there can be a large number of sessions at the standby member,

>     and sending synchronization exchanges for all of them may result in

>     overload, the standby member can choose to initiate the exchange in a

>     "lazy" fashion: only when it has to send or receive the request.  In

>     general, the standby member is free to initiate this exchange at its

>     discretion.

> ...

> 

> I've implemented the lazy sync, it's seems the best way to do it.

> 

>     Pekka

 

 

------------------------------

 

_______________________________________________

IPsec mailing list

IPsec@ietf.org

https://www.ietf.org/mailman/listinfo/ipsec

 

 

End of IPsec Digest, Vol 79, Issue 11

*************************************

--Boundary_(ID_yak7KriqKw7LIAYY1cjAmQ)-- From syedah@huawei.com Sun Nov 21 22:35:43 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8596F3A6ABF for ; Sun, 21 Nov 2010 22:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.594 X-Spam-Level: X-Spam-Status: No, score=-3.594 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5D9SKvBOWo4s for ; Sun, 21 Nov 2010 22:35:40 -0800 (PST) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 010EC3A6ABD for ; Sun, 21 Nov 2010 22:35:40 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC9007LKWYX9I@szxga05-in.huawei.com> for ipsec@ietf.org; Mon, 22 Nov 2010 14:35:21 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LC900BSMWYXE8@szxga05-in.huawei.com> for ipsec@ietf.org; Mon, 22 Nov 2010 14:35:21 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LC900G28WYWMM@szxml04-in.huawei.com> for ipsec@ietf.org; Mon, 22 Nov 2010 14:35:21 +0800 (CST) Date: Mon, 22 Nov 2010 12:05:19 +0530 From: Syed Ajim Hussain In-reply-to: <20101122061452.GE20162@oracle.com> To: 'Nicolas Williams' Message-id: <7EEB08E747E641CEB383B7AA290FAFF0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_sd7ZEpp/OFubLZYXbTwkAg)" Thread-index: AcuKDKHc5rQFF4wWTtuIojaOUCZ5SwAAUVkg References: <627E583314D94AF6B9E9CB08991E28BF@china.huawei.com> <20101122061452.GE20162@oracle.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] Generating Keying Material for the IKE_SA (IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 06:35:43 -0000 This is a multi-part message in MIME format. --Boundary_(ID_sd7ZEpp/OFubLZYXbTwkAg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT As per Nicolas Williams --> The key is that eavesdroppers cannot easily compute g^ir (mod p). The initiator computes g^ir = (g^r)^i mod p, while the responder computes g^ir = (g^i)^r mod p. The initiator knows i and the responder knows r. The attacker doesn't know i, nor r, because those are not sent. The attacker cannot easily compute them from g^i mod p nor g^r mod p. Nor can the attacker easily compute g^ir mod p from g^i and g^r mod p. The relevant number theory topic is known as the "Computational Diffie-Hellman Problem" (and the related Decisional Diffie-Hellman Problem). Syed Ajim --> Attacker can know who is initiator , who is responder , by the First IKE_INIT_SA Message , by Checking Responder Cookie Zero , Initiator will send --> g^I , in KE payload with DH Group no. in IKE_SA_INIT Message Responder will send --> g^R , in KE payload with DH Group no. IKE_SA_INIT Message So, in SKEYSEED = prf(Ni | Nr, g^ir), nothing is secret , if some attacker can capture IKE packets. So he can derive the Key also. With Regards Syed Ajim **************************************************************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! **************************************************************************** ________________________________ -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@oracle.com] Sent: Monday, November 22, 2010 11:45 AM To: Syed Ajim Hussain Subject: Re: [IPsec] Generating Keying Material for the IKE_SA (IKEv2) On Mon, Nov 22, 2010 at 11:25:26AM +0530, Syed Ajim Hussain wrote: > If attacker using some tools capturing all the IKE Packets from network, > he can easily generates the Keys. Although attacker can not establish a > SA without proper configuration information, but still he can easily get > the Keys, and he will be able to decrypt all the IKE Encrypted and > IPSEC Encrypted packets. > > Don't you think this is a big Security Risk? In IKEv1 Pre-shared key > auth, PSK was taken as part of key > > Calculation with is a secret to generate Key and provides some level of > Security. > > IKE Key generation process: > > SKEYSEED = prf(Ni | Nr, g^ir) ^^^^ The key is that eavesdroppers cannot easily compute g^ir (mod p). The initiator computes g^ir = (g^r)^i mod p, while the responder computes g^ir = (g^i)^r mod p. The initiator knows i and the responder knows r. The attacker doesn't know i, nor r, because those are not sent. The attacker cannot easily compute them from g^i mod p nor g^r mod p. Nor can the attacker easily compute g^ir mod p from g^i and g^r mod p. The relevant number theory topic is known as the "Computational Diffie-Hellman Problem" (and the related Decisional Diffie-Hellman Problem). Nico -- --Boundary_(ID_sd7ZEpp/OFubLZYXbTwkAg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

 

As  per Nicolas Williams -->

 

The key is that eavesdroppers cannot easily compute g^ir (mod p).

 

The initiator computes g^ir = (g^r)^i mod p, while the responder

computes g^ir = (g^i)^r mod p.  The initiator knows i and the responder

knows r.  The attacker doesn't know i, nor r, because those are not

sent.

 

The attacker cannot easily compute them from g^i mod p nor g^r mod p.

Nor can the attacker easily compute g^ir mod p from g^i and g^r mod p.

The relevant number theory topic is known as the "Computational

Diffie-Hellman Problem" (and the related Decisional Diffie-Hellman

Problem).

 

 

 

Syed Ajim -->

Attacker can know who is initiator , who is responder ,  by the First IKE_INIT_SA Message ,  by Checking Responder Cookie Zero , 

 

Initiator will send -->  g^I , in KE  payload with DH Group no. in  

                         IKE_SA_INIT  Message

Responder will send -->  g^R , in KE  payload with DH Group no.

                         IKE_SA_INIT  Message

 

 

So, in  SKEYSEED = prf(Ni | Nr, g^ir),  nothing is secret , if some attacker can capture IKE  packets.

So he can derive the Key also.

 

With Regards

Syed Ajim

 

 

 

****************************************************************************

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

 

****************************************************************************

________________________________

 

 

 

 

 

-----Original Message-----
From: Nicolas Williams [mailto:Nicolas.Williams@oracle.com]
Sent: Monday, November 22, 2010 11:45 AM
To: Syed Ajim Hussain
Subject: Re: [IPsec] Generating Keying Material for the IKE_SA (IKEv2)

 

On Mon, Nov 22, 2010 at 11:25:26AM +0530, Syed Ajim Hussain wrote:

>    If attacker using some tools capturing all the IKE Packets from network,

>    he can easily generates the Keys.  Although attacker can not establish a

>    SA without proper configuration information, but still he can easily get

>    the Keys, and he will be able to decrypt all  the  IKE Encrypted and 

>    IPSEC Encrypted packets.   

>

>    Don't you think this is a big Security Risk? In IKEv1 Pre-shared key

> auth, PSK was taken as  part of key

>

>    Calculation with is a secret to generate Key and provides some level of

> Security. 

>

>    IKE Key generation process:

>

>    SKEYSEED = prf(Ni | Nr, g^ir)

                             ^^^^

 

The key is that eavesdroppers cannot easily compute g^ir (mod p).

 

The initiator computes g^ir = (g^r)^i mod p, while the responder

computes g^ir = (g^i)^r mod p.  The initiator knows i and the responder

knows r.  The attacker doesn't know i, nor r, because those are not

sent.

 

The attacker cannot easily compute them from g^i mod p nor g^r mod p.

Nor can the attacker easily compute g^ir mod p from g^i and g^r mod p.

The relevant number theory topic is known as the "Computational

Diffie-Hellman Problem" (and the related Decisional Diffie-Hellman

Problem).

 

Nico

--

--Boundary_(ID_sd7ZEpp/OFubLZYXbTwkAg)-- From kivinen@iki.fi Mon Nov 22 07:02:22 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69FEE3A69D5 for ; Mon, 22 Nov 2010 07:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnt0M++JCprn for ; Mon, 22 Nov 2010 07:02:21 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 4F2143A69C9 for ; Mon, 22 Nov 2010 07:02:20 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id oAMF3AQL005965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Nov 2010 17:03:10 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id oAMF396p014539; Mon, 22 Nov 2010 17:03:09 +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: <19690.34349.494773.408592@fireball.kivinen.iki.fi> Date: Mon, 22 Nov 2010 17:03:09 +0200 From: Tero Kivinen To: Pekka Riikonen In-Reply-To: References: <4CDC08CF.8030106@gmail.com> <19686.24984.949221.628414@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: IPsecme WG Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 15:02:22 -0000 Pekka Riikonen writes: > Isn't this what the -02 draft specifies? Not sure, as I have not yet read the -02 draft fully. > ... > o The active member dies, and a standby member takes over. The > standby member sends its own idea of the IKE Message IDs (both > incoming and outgoing) to the peer in an Informational message > exchange with Message ID zero. > o The peer first authenticates the message and then validates the > failover count. The peer compares the received values with the > values available locally and picks the higher value. It then > updates its Message IDs with the higher values and also propose > the same values in its response. > ... This still has the failover count, which is not needed, as if we always take the max of message IDs seen by both parties, then we cannot go backwards, and replays etc do not matter, as we end up in same state (i.e. if someone replays request, the other end will set the message IDs to be the largest value seen). We still need nonce, to know that the reply matches the request, i.e. so someone cannot replay old reply, altough in most cases the reply would have smaller numbers than what was in the request, in which case the sender will immediately know something is wrong. -- kivinen@iki.fi From Anil.Maguluri@lntinfotech.com Mon Nov 22 21:09:21 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DEA328C0DC for ; Mon, 22 Nov 2010 21:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Itds2gBFYWvf for ; Mon, 22 Nov 2010 21:09:20 -0800 (PST) Received: from mail192.messagelabs.com (mail192.messagelabs.com [216.82.241.243]) by core3.amsl.com (Postfix) with ESMTP id 2FC943A6A29 for ; Mon, 22 Nov 2010 21:09:19 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: Anil.Maguluri@lntinfotech.com X-Msg-Ref: server-10.tower-192.messagelabs.com!1290489012!58956694!1 X-StarScan-Version: 6.2.9; banners=lntinfotech.com,-,- X-Originating-IP: [203.101.96.7] Received: (qmail 7296 invoked from network); 23 Nov 2010 05:10:15 -0000 Received: from unknown (HELO BLRINMSHTCAS01.bglrodc.lntinfotech.com) (203.101.96.7) by server-10.tower-192.messagelabs.com with AES128-SHA encrypted SMTP; 23 Nov 2010 05:10:15 -0000 Received: from blrinmsmbx01.bglrodc.lntinfotech.com ([169.254.1.155]) by BLRINMSHTCAS01.bglrodc.lntinfotech.com ([172.28.0.81]) with mapi; Tue, 23 Nov 2010 10:40:12 +0530 From: Anil Maguluri To: "ipsec@ietf.org" Date: Tue, 23 Nov 2010 10:40:04 +0530 Thread-Topic: Clarification regarding AH Header Length Thread-Index: AcuKzK/xDPrnXCFPQtmwGZTcjXQ/3Q== Message-ID: <903D13EA90218E43BA0881BC8B569C7D0F8B8FB7B1@BLRINMSMBX01.bglrodc.lntinfotech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_903D13EA90218E43BA0881BC8B569C7D0F8B8FB7B1BLRINMSMBX01b_" MIME-Version: 1.0 Subject: [IPsec] Clarification regarding AH Header Length X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 05:09:21 -0000 --_000_903D13EA90218E43BA0881BC8B569C7D0F8B8FB7B1BLRINMSMBX01b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, Please clarify me the below query. =E8 When AH Header Length becomes zero (in which scenario)? =E8 If the length is zero, means no SN and AH Data wont be available in th= e packet. Regards, Anil Kumar Maguluri ________________________________ This Email may contain confidential or privileged information for the inte= nded recipient (s) If you are not the intended recipient, please do not us= e or disseminate the information, notify the sender and delete it from you= r system. ______________________________________________________________________ --_000_903D13EA90218E43BA0881BC8B569C7D0F8B8FB7B1BLRINMSMBX01b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All,

 

Please clarify me the below query.

 

=E8 When AH Header Length becomes zero (in whic= h scenario)?

=E8 If the length is zero, means no SN and AH D= ata wont be available in the packet.

 

Regards,
Anil Kumar Maguluri


This Email may contain con= fidential or privileged information for the intended recipient (s) If you = are not the intended recipient, please do not use or disseminate the infor= mation, notify the sender and delete it from your system.
______________________________________________________________________
= --_000_903D13EA90218E43BA0881BC8B569C7D0F8B8FB7B1BLRINMSMBX01b_-- From kivinen@iki.fi Tue Nov 23 05:06:01 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B5483A693E for ; Tue, 23 Nov 2010 05:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdbDP5nkipsj for ; Tue, 23 Nov 2010 05:06:00 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 655663A6924 for ; Tue, 23 Nov 2010 05:05:59 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id oAND6owE023869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Nov 2010 15:06:50 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id oAND6nSu023991; Tue, 23 Nov 2010 15:06:49 +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: <19691.48233.734358.997141@fireball.kivinen.iki.fi> Date: Tue, 23 Nov 2010 15:06:49 +0200 From: Tero Kivinen To: Pekka Riikonen In-Reply-To: References: <4CDC08CF.8030106@gmail.com> <19686.24984.949221.628414@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 17 min X-Total-Time: 16 min Cc: IPsecme WG Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 13:06:01 -0000 Pekka Riikonen writes: > : Now the real question is what are we going to do with the exchanges > : which are still in progress when the sync message is received, and how > : do we recover when we notice that we do have missed IKE messages, > : meaning we have created, rekeyed or deleted some Child SA in those > : messages we lost because of failover. > : > Draft specifies what to do here as well, at least partly. Also note that > you may never notice missed IKE messages because they happened in the > failed cluster node. Normal crash recovery takes care of any desync > problems that may have happened. Define "normal crash recover". We did get rid of most of the crash recovery stuff in the IKEv2 compared to IKEv1. In RFC5996 we have text saying: "If connection state becomes sufficiently messed up, a node MAY close the IKE SA, as described above. It can then rebuild the SAs it needs on a clean base under a new IKE SA." In section 1.5 we also have text saying: o If an ESP or AH packet arrives with an unrecognized SPI. This might be due to the receiving node having recently crashed and lost state, or because of some other system malfunction or attack. ... In the first case, if the receiving node has an active IKE SA to the IP address from whence the packet came, it MAY send an INVALID_SPI notification of the wayward packet over that IKE SA in an INFORMATIONAL exchange. The Notification Data contains the SPI of the invalid packet. The recipient of this notification cannot tell whether the SPI is for AH or ESP, but this is not important because the SPIs are supposed to be different for the two. But there is no real description what to do when we receive INVALID_SPI message (most likely the Child SA will be deleted by sending normal delete notification, but as the other end will not know anything about the Child SA it will not reply this message and this will result in half-closed Child SA, where the section 1.4.1 says: Half-closed ESP or AH connections are anomalous, and a node with auditing capability should probably audit their existence if they persist. Note that this specification does not specify time periods, so it is up to individual endpoints to decide how long to wait. A node MAY refuse to accept incoming data on half-closed connections but MUST NOT unilaterally close them and reuse the SPIs. meaning even when host which did not crash sends delete for the Child SA which is not there anymore the crashed host will not reply and the Child SA stays in half-closed state. The RFC 5996 solution to this is to delete the IKE SA and start over. If we want to do something different here we need define the behavior here. > ... > o The peer should not wait for any pending responses while > responding with the new Message ID values. For example, if the > window size is 5 and the peer's window is 3-7, and if the peer has > sent requests 3, 4, 5, 6, 7 and received responses only for 4, 5, > 6, 7 but not for 3, then it should include the value 8 in its > EXPECTED_SEND_REQ_MESSAGE_ID payload and should not wait for a > response to message 3 anymore. This opens new attacks, because now receiving sync message with message ID zero has also other effects than just syncing the max message ID for future use, it also causes existing exchanges to be destroyed. I.e. if host A and B have done sync earlier, meaning attacker has a copy of IKE SA Message ID sync message having message ID of zero, then attacker can wait for host B to start few exchanges and then reply the old sync message. If host A now immediately while processing the request destroys old existing exchanges then this allows attackers to delete exchanges at will. Nonce in the Message ID sync message will not help in this case, but the failover counter will help, as in that case the host A will reject the replay because of the reused failover counter. What should host A do if it DOES receive replies for those missing messages? > o Similarly, the peer should also not wait for pending (incoming) > requests. For example if the window size is 5 and the peer's > window is 3-7 and if the peer has received requests 4, 5, 6, 7 but > not 3, then it should send the value 8 in the > EXPECTED_RECV_REQ_MESSAGE_ID payload, and should not expect to > receive message 3 anymore. > ... Again what should the peer do if it does get those messages? Ignore them? Process them? If they are sent before the crash and were delayed in the network, and arrived after the sync message, they were most likely from the previous incarnation of the other end, thus most likely they need to be ignored. > Are the Security Considerations in the draft valid anymore at all? And > are the nonce and failover count needed? Yaron wanted to eliminate these, > and I'm all for it. I think we still need both. The failover counter protects against the attack I explained in this email (i.e. attacker replaying request), and nonce protects against the attacks where attacker tries to replay response message. -- kivinen@iki.fi From priikone@iki.fi Tue Nov 23 06:38:05 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1521A3A6973 for ; Tue, 23 Nov 2010 06:38:05 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Q+d8Wp-A-RI for ; Tue, 23 Nov 2010 06:38:03 -0800 (PST) Received: from otaku.Xtrmntr.org (sauna.silcnet.org [IPv6:2001:4118:10:4000::2205]) by core3.amsl.com (Postfix) with ESMTP id B6EBC3A6969 for ; Tue, 23 Nov 2010 06:38:02 -0800 (PST) Received: by otaku.Xtrmntr.org (Postfix, from userid 201) id 616164952; Tue, 23 Nov 2010 15:41:07 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by otaku.Xtrmntr.org (Postfix) with ESMTP id 5F87A48AC; Tue, 23 Nov 2010 15:41:07 +0100 (CET) Date: Tue, 23 Nov 2010 15:41:06 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: Tero Kivinen In-Reply-To: <19691.48233.734358.997141@fireball.kivinen.iki.fi> Message-ID: References: <4CDC08CF.8030106@gmail.com> <19686.24984.949221.628414@fireball.kivinen.iki.fi> <19691.48233.734358.997141@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: IPsecme WG Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 14:38:05 -0000 : Define "normal crash recover". We did get rid of most of the crash : recovery stuff in the IKEv2 compared to IKEv1. In RFC5996 we have text : saying: : I was talking about INVALID_SPI notify. : But there is no real description what to do when we receive : INVALID_SPI message (most likely the Child SA will be deleted by : sending normal delete notification, but as the other end will not know : anything about the Child SA it will not reply this message and this : will result in half-closed Child SA, where the section 1.4.1 says: : I don't think sending delete notification after receiving INVALID_SPI (over IKE SA) is appropriate. The other end has already told you it doesn't have the SA. It should be just deleted without notification. Isn't this the typical thing to do? : What should host A do if it DOES receive replies for those missing : messages? : It can't do anything because it doesn't have any state for those responses. They existed in the crashed node. And, they are behind the new window anyway so they are dropped. : > o Similarly, the peer should also not wait for pending (incoming) : > requests. For example if the window size is 5 and the peer's : > window is 3-7 and if the peer has received requests 4, 5, 6, 7 but : > not 3, then it should send the value 8 in the : : Again what should the peer do if it does get those messages? Ignore : them? Process them? If they are sent before the crash and were delayed : in the network, and arrived after the sync message, they were most : likely from the previous incarnation of the other end, thus most : likely they need to be ignored. : Again, they are behind the new window and will be dropped. As long as both ends follow the protocol both ends should have deleted the states for any pending requests and responses and moved the window, and any stray packets from the network should now fall behind the window and are simply dropped. Pekka From kivinen@iki.fi Tue Nov 23 07:13:54 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3857C3A6961 for ; Tue, 23 Nov 2010 07:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHTiNKnCA+jf for ; Tue, 23 Nov 2010 07:13:52 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id AA0D73A695A for ; Tue, 23 Nov 2010 07:13:51 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id oANFEjUP025405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Nov 2010 17:14:45 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id oANFEjta006626; Tue, 23 Nov 2010 17:14:45 +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: <19691.55909.326260.368178@fireball.kivinen.iki.fi> Date: Tue, 23 Nov 2010 17:14:45 +0200 From: Tero Kivinen To: Pekka Riikonen In-Reply-To: References: <4CDC08CF.8030106@gmail.com> <19686.24984.949221.628414@fireball.kivinen.iki.fi> <19691.48233.734358.997141@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 22 min X-Total-Time: 22 min Cc: IPsecme WG Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 15:13:54 -0000 Pekka Riikonen writes: > I don't think sending delete notification after receiving INVALID_SPI > (over IKE SA) is appropriate. The other end has already told you it > doesn't have the SA. It should be just deleted without notification. > Isn't this the typical thing to do? The other end is telling that he does not have incoming SPI given that number. The peer is sending message saying he wants to delete the pair of that SPI meaning is incoming SPI of the same Child SA pair. It is not exactly same thing. It could perhaps be interperted that as other end send INVALID_SPI for his inbound SPI, then that SA is not there, so peer should not wait for the corresponding delete with that SPI to his request to delete his own inbound SA. RFC5996 still says that "A node MAY refuse to accept incoming data on half-closed connections but MUST NOT unilaterally close them and reuse the SPIs." which quite clearly say that node who still has SA up, cannot silently remove his inbound SPI and reuse the SPI, but must send delete for it before reusing it. I think correct way to handle INVALID_SPI is that consider it as same as the other end would have sent delete for that his inbound SPI listed in the notification, and then send corresponding delete for your inbound SPI, which the other end will ignore as specified in the 2.25.1: ... If a peer receives a request to close a Child SA that does not exist, it SHOULD reply without a Delete payload. But anyways, as I have requested before I think we need to add text for different cases and how to recover them. I.e. how to handle following situations (Host B1 is the one who has lost state, Host B2 is the new instance missing some state): 1) Host A has sent CREATE_CHILD_SA and got reply to that from B1, but B2 does not know anything about it and host A tries to send traffic to that SA. 2) Host A has sent CREATE_CHILD_SA and got reply to that from B1, but B2 does not know anything about it and host A tries to rekey that SA. 3) Host A has sent CREATE_CHILD_SA and got reply to that from B1, but B2 does not know anything about it and host A tries to delete that SA. 4) Host A has sent CREATE_CHILD_SA and but has not received anything from host B before getting sync message ID notification from B2. 5) Host A has sent Delete payload in INFORMATIONAL exchange to B1 and has received reply from B1, but now B2 continues sending data to the SA which has already been deleted. 6) Host A has sent Delete payload in INFORMATIONAL exchange to B1 but has not received anything from host B before getting sync message ID nortification from B2. 7) Host B1 has sent CREATE_CHILD_SA and got reply to that from A, but B2 does not know anything about it and host A tries to send traffic to that SA. 8) Host B1 has sent CREATE_CHILD_SA and got reply to that from A, but B2 does not know anything about it and host A tries to rekey that SA. 9) Host B1 has sent CREATE_CHILD_SA and got reply to that from A, but B2 does not know anything about it and host A tries to delete that SA. 10) Host B1 has sent Delete payload in INFORMATIONAL exchange to A and has received reply from A, but now B2 continues sending data to the SA which has already been deleted. 11) Similar cases for IKE SA rekeying and deletion. I would expect we can create generic rules for handling most of those cases, but I think it is important to analyze all cases (like RFC4718 and RFC5996 did, i.e. RFC4718 did analyze lots of cases, and RFC5996 includes generic rules which covers the cases analyzed in the RFC4718). Creating those generic rules is impossible unless we really go through what happens in each situation. > : What should host A do if it DOES receive replies for those missing > : messages? > : > It can't do anything because it doesn't have any state for those > responses. They existed in the crashed node. And, they are behind > the new window anyway so they are dropped. Yes, but what should it do next? If that was delete notification, should it retry (most likely yes)? If this was IKE SA rekey notification, then it is not supposed to send anything else than delete for IKE SA after CREATE_CHILD_SA exchang rekeying IKE SA etc. Those cases needs to be analyzed and checked out what is the correct handling for them. This is timeconsuming task (I remember that Pasi complained that when he analyzed the collision cases in the RFC4718 it took some time) and I do not have time to do that, so I would expect the draft to cover those cases. > : > o Similarly, the peer should also not wait for pending (incoming) > : > requests. For example if the window size is 5 and the peer's > : > window is 3-7 and if the peer has received requests 4, 5, 6, 7 but > : > not 3, then it should send the value 8 in the > : > : Again what should the peer do if it does get those messages? Ignore > : them? Process them? If they are sent before the crash and were delayed > : in the network, and arrived after the sync message, they were most > : likely from the previous incarnation of the other end, thus most > : likely they need to be ignored. > : > Again, they are behind the new window and will be dropped. > > As long as both ends follow the protocol both ends should have deleted the > states for any pending requests and responses and moved the window, and > any stray packets from the network should now fall behind the window and > are simply dropped. Even if we are agreeing what should be done for those messages, we need text in the document explaining those cases and how to handle them. -- kivinen@iki.fi From yaronf.ietf@gmail.com Tue Nov 23 07:14:15 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE46428C111 for ; Tue, 23 Nov 2010 07:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-+C5+ivDjVQ for ; Tue, 23 Nov 2010 07:14:15 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id DB06C3A6961 for ; Tue, 23 Nov 2010 07:14:14 -0800 (PST) Received: by wyb29 with SMTP id 29so8415395wyb.31 for ; Tue, 23 Nov 2010 07:15:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=NtkxBqxbr/Qgs1ZtSZxI/3paHycSxZZItD/4lbK0aCs=; b=bwwkjaqSld5gapjhhDyebv6NP3ImaM/WO1qJvIFTmS80cREgYxC8dIUFd+ig+p/rCy qy/n1W+tzu1bMuEyC9AlXL63TYspHguKURYlq0I2FfNo+XVnbogjQrAt2uvy0uVLqxo/ GGhuaS1SnCft2c+M//or4eOKbNeEFBco754Ko= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=xuBoHejuhZrc2N4DuOkFOK/rmJAgyxNFbaQ9pmQbq/vMyFzxVgI7QAMKd+sTq3OuLm yydCG96mZAUG8lDaVjxpPTnjuvtJ9/xz8UM+6D9RhXHVrFIqptxZE33nbNTGE3HizlSP doH9NnDgQnjctR8hJVZPQumpVBXBE1eDAnzZc= Received: by 10.227.134.149 with SMTP id j21mr7720701wbt.194.1290525310372; Tue, 23 Nov 2010 07:15:10 -0800 (PST) Received: from [10.0.0.1] (bzq-79-181-24-102.red.bezeqint.net [79.181.24.102]) by mx.google.com with ESMTPS id b30sm4179739wbb.22.2010.11.23.07.15.01 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Nov 2010 07:15:04 -0800 (PST) Message-ID: <4CEBDA72.6040901@gmail.com> Date: Tue, 23 Nov 2010 17:14:58 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Tero Kivinen References: <4CDC08CF.8030106@gmail.com> <19686.24984.949221.628414@fireball.kivinen.iki.fi> <19691.48233.734358.997141@fireball.kivinen.iki.fi> In-Reply-To: <19691.48233.734358.997141@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Pekka Riikonen Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 15:14:16 -0000 Hi Tero, to reiterate: if you ensure that the Message ID value is always strictly larger than in previous messages (i.e. if the failover member sends old_value+delta for a large enough delta, and if the peer is willing to accepts arbitrary jumps in the value) then both sides can protect against replay without requiring either the nonce or the failover counter. But this means that the Message ID value is *set* to a new value on both sides, rather than *synchronized* (to a previous value). Thanks, Yaron On 11/23/2010 03:06 PM, Tero Kivinen wrote: > Pekka Riikonen writes: > >> Are the Security Considerations in the draft valid anymore at all? And >> are the nonce and failover count needed? Yaron wanted to eliminate these, >> and I'm all for it. > > I think we still need both. The failover counter protects against the > attack I explained in this email (i.e. attacker replaying request), > and nonce protects against the attacks where attacker tries to replay > response message. From kivinen@iki.fi Tue Nov 23 07:18:55 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42DFD3A6974 for ; Tue, 23 Nov 2010 07:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XN9Je3AeDGds for ; Tue, 23 Nov 2010 07:18:54 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 248753A6961 for ; Tue, 23 Nov 2010 07:18:53 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id oANFJoKL001771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Nov 2010 17:19:50 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id oANFJn4U026308; Tue, 23 Nov 2010 17:19:50 +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: <19691.56213.969437.881301@fireball.kivinen.iki.fi> Date: Tue, 23 Nov 2010 17:19:49 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <4CEBDA72.6040901@gmail.com> References: <4CDC08CF.8030106@gmail.com> <19686.24984.949221.628414@fireball.kivinen.iki.fi> <19691.48233.734358.997141@fireball.kivinen.iki.fi> <4CEBDA72.6040901@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: IPsecme WG , Pekka Riikonen Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 15:18:55 -0000 Yaron Sheffer writes: > to reiterate: if you ensure that the Message ID value is always strictly > larger than in previous messages (i.e. if the failover member sends > old_value+delta for a large enough delta, and if the peer is willing to > accepts arbitrary jumps in the value) then both sides can protect > against replay without requiring either the nonce or the failover > counter. But this means that the Message ID value is *set* to a new > value on both sides, rather than *synchronized* (to a previous value). Except there is no way to know the value of delta. And if you do not know value of delta, then you open yourself to replay attacks if your delta was too small. Having some arbitrary delta, which is impossible to pick properly, isn't really solving the problem, it just makes the attacks bit harder for the attacker, but it does not remove those attacks. -- kivinen@iki.fi From yaronf.ietf@gmail.com Tue Nov 23 07:35:00 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 111AE28C1EC for ; Tue, 23 Nov 2010 07:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVO2sLlPuoLB for ; Tue, 23 Nov 2010 07:34:55 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 7E93228C118 for ; Tue, 23 Nov 2010 07:27:34 -0800 (PST) Received: by wyb29 with SMTP id 29so8428897wyb.31 for ; Tue, 23 Nov 2010 07:28:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=IEDksF1Nu1EH7fP703of+q9XRIzJwkNWRvFhKs1M6xg=; b=HrdYOY19Af97675fqVg5jhKFwCmZjl0wR2X3MjU2mmY4bEXpOMnXbQS+KY1SKhzLJk +92uCTQ/dgbQahOB/INFNSpXVL2bkz43tU+RAdMF2HfuV7xE8/aiPaMk313AGFto9WAT Z6CUMRU4+/P74mUmfmTGKGR9SJG7cn/WNVz8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=fC1q4tDe2lWfLoLdF3gu7ryoV3EOqpPrp5R4Mp4l3zCeUFkbb+yschMEdS7xnhHme8 jQBTH25NKteSQKeJVLCvVkhPJnFLqzqbaO8AfoS1+TbG8+z9c1MtsbUrwpjxkbRV6Ld2 CZIju2ra3SsJX3ofthDGnCiR45ViAxzmJ/gUM= Received: by 10.227.155.15 with SMTP id q15mr7865793wbw.141.1290526110782; Tue, 23 Nov 2010 07:28:30 -0800 (PST) Received: from [10.0.0.1] (bzq-79-181-24-102.red.bezeqint.net [79.181.24.102]) by mx.google.com with ESMTPS id b30sm4186833wbb.10.2010.11.23.07.28.27 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Nov 2010 07:28:29 -0800 (PST) Message-ID: <4CEBDD98.8060808@gmail.com> Date: Tue, 23 Nov 2010 17:28:24 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Tero Kivinen References: <4CDC08CF.8030106@gmail.com> <19686.24984.949221.628414@fireball.kivinen.iki.fi> <19691.48233.734358.997141@fireball.kivinen.iki.fi> <4CEBDA72.6040901@gmail.com> <19691.56213.969437.881301@fireball.kivinen.iki.fi> In-Reply-To: <19691.56213.969437.881301@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Pekka Riikonen Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 15:35:00 -0000 It is the receiver's responsibility to protect against replays. So the down side is, if your delta is too low, the message you send will be dropped and you will have to re-establish the SA. You do not open yourself to a replay. IOW, it's a matter of implementation: you need to ensure that the peers are synchronized well enough so that you can use a small delta (e.g. 1-2). Thanks, Yaron On 11/23/2010 05:19 PM, Tero Kivinen wrote: > Yaron Sheffer writes: >> to reiterate: if you ensure that the Message ID value is always strictly >> larger than in previous messages (i.e. if the failover member sends >> old_value+delta for a large enough delta, and if the peer is willing to >> accepts arbitrary jumps in the value) then both sides can protect >> against replay without requiring either the nonce or the failover >> counter. But this means that the Message ID value is *set* to a new >> value on both sides, rather than *synchronized* (to a previous value). > > Except there is no way to know the value of delta. And if you do not > know value of delta, then you open yourself to replay attacks if your > delta was too small. > > Having some arbitrary delta, which is impossible to pick properly, > isn't really solving the problem, it just makes the attacks bit harder > for the attacker, but it does not remove those attacks. From priikone@iki.fi Wed Nov 24 01:33:34 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DFFF3A6A14 for ; Wed, 24 Nov 2010 01:33:34 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0CyUJHsmZMP for ; Wed, 24 Nov 2010 01:33:33 -0800 (PST) Received: from otaku.Xtrmntr.org (sauna.silcnet.org [IPv6:2001:4118:10:4000::2205]) by core3.amsl.com (Postfix) with ESMTP id AC9C63A680A for ; Wed, 24 Nov 2010 01:33:32 -0800 (PST) Received: by otaku.Xtrmntr.org (Postfix, from userid 201) id C67AD495D; Wed, 24 Nov 2010 10:36:41 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by otaku.Xtrmntr.org (Postfix) with ESMTP id C501B4947; Wed, 24 Nov 2010 10:36:41 +0100 (CET) Date: Wed, 24 Nov 2010 10:36:41 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: Tero Kivinen In-Reply-To: <19691.55909.326260.368178@fireball.kivinen.iki.fi> Message-ID: References: <4CDC08CF.8030106@gmail.com> <19686.24984.949221.628414@fireball.kivinen.iki.fi> <19691.48233.734358.997141@fireball.kivinen.iki.fi> <19691.55909.326260.368178@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: IPsecme WG Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 09:33:34 -0000 On Tue, 23 Nov 2010, Tero Kivinen wrote: : I think correct way to handle INVALID_SPI is that consider it as same : as the other end would have sent delete for that his inbound SPI : listed in the notification, and then send corresponding delete for : your inbound SPI, which the other end will ignore as specified in the : 2.25.1: : I'm not sure I agree. I think it's reasonable to assume that if you receive INVALID_SPI notification instead of delete notification is that the remote end has crashed or there is something else terribly wrong with it and that it most likely doesn't have any state for the SA pair. In which case sending a delete notification would be redundant. And even if you are wrong and the other end has the outbound SA, you will now start receiving packets with unknown SPI and will eventually reply with INVALID_SPI. Hence, the situation resolves itself. The text you quote are from the section dealing with delete notifications. But since the RFC doesn't specify what to do with INVALID_SPI I think this is a _reasonable_ assumption, especially since this is what is says about it: o If an ESP or AH packet arrives with an unrecognized SPI. This might be due to the receiving node having recently crashed and lost state, or because of some other system malfunction or attack. In the first case, if the receiving node has an active IKE SA to the IP address from whence the packet came, it MAY send an INVALID_SPI notification of the wayward packet over that IKE SA in an INFORMATIONAL exchange. It especially mentions crashed node with sending INVALID_SPI. I know, it doesn't say what to do (and it's MAY), but I think it's best to handle INVALID_SPI and delete notification differently. It's unfortunate this was left ambiguous. : > It can't do anything because it doesn't have any state for those : > responses. They existed in the crashed node. And, they are behind : > the new window anyway so they are dropped. : : Yes, but what should it do next? If that was delete notification, : should it retry (most likely yes)? If this was IKE SA rekey : notification, then it is not supposed to send anything else than : delete for IKE SA after CREATE_CHILD_SA exchang rekeying IKE SA etc. : The first thing here is that we don't know what kind of exchanges they were. In a typical cluster implementation all nodes would have the full state, that is they have all IKE SAs and IPSEC SAs, and all nodes know when they expire and when rekeys need to be started. The node should know for example that IKE SA expired during the failover transition and perhaps it's best to delete it instead of trying to do anything else with it (and send N(INITIAL_CONTACT) with possible new negotiation). I'm not sure. If the IKE SA rekey happened the sync protocol will fail and the IKE SA would be deleted. The node doesn't have the new IKE SA either and that SA will probably get deleted too. Unfortunately, this all takes time to resolve. The IPSEC SA desync problem (new SA, rekeyed, deleted) would resolve itself if we have consistent way of handling the INVALID_SPI. Okay, here's my take on this: : 1) Host A has sent CREATE_CHILD_SA and got reply to that from B1, but : B2 does not know anything about it and host A tries to send traffic : to that SA. : INVALID_SPI fixes (assuming we agree its handling). Delete notification fixes too but will result into half-closed SA for the A's inbound SA. The host A will never receive any traffic to that SA. : 2) Host A has sent CREATE_CHILD_SA and got reply to that from B1, but : B2 does not know anything about it and host A tries to rekey that : SA. : So this would be case where the SA never had any traffic and is merely rekeyed. This is specified in RFC 5996 section 2.25.1: If a peer receives a request to rekey a Child SA that does not exist, it SHOULD reply with CHILD_SA_NOT_FOUND. I guess it should delete it. : 3) Host A has sent CREATE_CHILD_SA and got reply to that from B1, but : B2 does not know anything about it and host A tries to delete that : SA. : Same section as above: If a peer receives a request to close a Child SA that does not exist, it SHOULD reply without a Delete payload. The B2 will never send any traffic to the SA because it doesn't have it. : 4) Host A has sent CREATE_CHILD_SA and but has not received anything : from host B before getting sync message ID notification from B2. : Covered by the draft. It deletes the pending request. It can retry later. : 5) Host A has sent Delete payload in INFORMATIONAL exchange to B1 and : has received reply from B1, but now B2 continues sending data to : the SA which has already been deleted. : INVALID_SPI fixes (assuming we agree its handling). Delete notification fixes too but will result into half-closed SA for the B2's inbound SA. The host B2 will never receive any traffic to that SA. : 6) Host A has sent Delete payload in INFORMATIONAL exchange to B1 but : has not received anything from host B before getting sync message : ID nortification from B2. : Covered by the draft. It deletes the pending request. It can retry later. : 7) Host B1 has sent CREATE_CHILD_SA and got reply to that from A, but : B2 does not know anything about it and host A tries to send traffic : to that SA. : Same as 1. : 8) Host B1 has sent CREATE_CHILD_SA and got reply to that from A, but : B2 does not know anything about it and host A tries to rekey that : SA. : Same as 2. : 9) Host B1 has sent CREATE_CHILD_SA and got reply to that from A, but : B2 does not know anything about it and host A tries to delete that : SA. : Same as 3. : 10) Host B1 has sent Delete payload in INFORMATIONAL exchange to A and : has received reply from A, but now B2 continues sending data to : the SA which has already been deleted. : Same as 5, different sides. I don't see anything that prevents working connections. Pekka From kivinen@iki.fi Wed Nov 24 03:17:33 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD95428B797 for ; Wed, 24 Nov 2010 03:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKujXPUx+Lly for ; Wed, 24 Nov 2010 03:17:32 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id EA3D028C153 for ; Wed, 24 Nov 2010 03:17:31 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id oAOBIPZe008281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Nov 2010 13:18:25 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id oAOBIOI1003174; Wed, 24 Nov 2010 13:18:24 +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: <19692.62592.608771.229675@fireball.kivinen.iki.fi> Date: Wed, 24 Nov 2010 13:18:24 +0200 From: Tero Kivinen To: Pekka Riikonen In-Reply-To: References: <4CDC08CF.8030106@gmail.com> <19686.24984.949221.628414@fireball.kivinen.iki.fi> <19691.48233.734358.997141@fireball.kivinen.iki.fi> <19691.55909.326260.368178@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 31 min X-Total-Time: 59 min Cc: IPsecme WG Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 11:17:33 -0000 Pekka Riikonen writes: > > On Tue, 23 Nov 2010, Tero Kivinen wrote: > : I think correct way to handle INVALID_SPI is that consider it as same > : as the other end would have sent delete for that his inbound SPI > : listed in the notification, and then send corresponding delete for > : your inbound SPI, which the other end will ignore as specified in the > : 2.25.1: > : > I'm not sure I agree. I think it's reasonable to assume that if you > receive INVALID_SPI notification instead of delete notification is that > the remote end has crashed or there is something else terribly wrong with > it and that it most likely doesn't have any state for the SA pair. General principle in the IKEv2 is that it is reliable protocol, and the state should not get out of sync. If you are getting INVALID_SPI for SA which you think is valid that means that other end is doing something wrong (for base IKEv2 case). The assumption in IKEv2 is that if IKE SA is working, then all the child SAs negotiated with it are also working. If some Child SA can only be removed by sending delete notification or by deleting whole IKE SA. There is text in the RFC5996 explaining that in several places, altough it is splitted around so it might not be that clear: Receipt of a fresh cryptographically protected message on an IKE SA or any of its Child SAs ensures liveness of the IKE SA and all of its Child SAs. Note that this places requirements on the failure modes of an IKE endpoint. An implementation needs to stop sending over any SA if some failure prevents it from receiving on all of the associated SAs. If a system creates Child SAs that can fail independently from one another without the associated IKE SA being able to send a delete message, then the system MUST negotiate such Child SAs using separate IKE SAs. ... If an IKE endpoint chooses to delete Child SAs, it MUST send Delete payloads to the other end notifying it of the deletion. Because there is no normal case where INVALID_SPI would be sent inside the IKE SA in normal IKEv2 there is no processing rules for it in the RFC5996. As it seems we do need processing rules for it when used in high availability IKEv2 then that text needs to be in this document. > In which case sending a delete notification would be redundant. Most likely yes, but IKEv2 says you do not delete SAs without sending delete payloads. If we want to modify IKEv2 we need to state so explictly, not just assume people do same assumptions on the missing text in RFC5996. > And even if you are wrong and the other end has the outbound SA, you > will now start receiving packets with unknown SPI and will > eventually reply with INVALID_SPI. Hence, the situation resolves > itself. Most likely yes, or the other end assumes that state is messed up, and deletes the whole IKE SA, and starts over (which is what RFC5996 suggests). > The text you quote are from the section dealing with delete > notifications. But since the RFC doesn't specify what to do with > INVALID_SPI I think this is a _reasonable_ assumption, especially > since this is what is says about it: It is better not to assume people do things same way unless explictly specified, which is why I think the new high availibility protocol needs to have text explaining these situations. I do not really care which way the text is written as long as it is there and tells how to handle these situations. > o If an ESP or AH packet arrives with an unrecognized SPI. This > might be due to the receiving node having recently crashed and > lost state, or because of some other system malfunction or attack. > > In the first case, if the receiving node has an active IKE SA to the > IP address from whence the packet came, it MAY send an INVALID_SPI > notification of the wayward packet over that IKE SA in an > INFORMATIONAL exchange. > > It especially mentions crashed node with sending INVALID_SPI. I know, it > doesn't say what to do (and it's MAY), but I think it's best to handle > INVALID_SPI and delete notification differently. It's unfortunate this > was left ambiguous. Note, that the assumption here is that the unrecognized SPI here is not negotiated over the same IKE SA over which the INVALID_SPI is sent, thus there is no point of sending delete notifications or anything similar over the new IKE SA we have with the peer. It is assumed that the INVALID_SPI for SPI x belonging to the old IKE SA will most likely trigger liveness check on that old IKE SA, which will then fail as the other end has rebooted and that will cause old IKE SA and the Child SAs being deleted. IKEv2 do assume that if IKE SA is up, then all Child SAs are also up, unless explictly deleted. The text above does not even try to cover high availibility cases, as they were outside the scope of original IKEv2 (and IKEv2bis) work. > The first thing here is that we don't know what kind of exchanges they > were. The one who is throwing away the exchanges he is trying to do, does know what those are. If the exchanges are already finished then there is no way to know what they were, and whether they were processed by the other end or whether they were transferred to the fall back pair. > Okay, here's my take on this: That is good start, but it should be put to the draft to be useful. > : 1) Host A has sent CREATE_CHILD_SA and got reply to that from B1, but > : B2 does not know anything about it and host A tries to send traffic > : to that SA. > : > INVALID_SPI fixes (assuming we agree its handling). Delete notification > fixes too but will result into half-closed SA for the A's inbound SA. The > host A will never receive any traffic to that SA. I agree on that. Adding text for INVALID_SPI handling would most likely be best. > : 2) Host A has sent CREATE_CHILD_SA and got reply to that from B1, but > : B2 does not know anything about it and host A tries to rekey that > : SA. > : > So this would be case where the SA never had any traffic and is merely > rekeyed. This is specified in RFC 5996 section 2.25.1: > > If a peer receives a > request to rekey a Child SA that does not exist, it SHOULD reply with > CHILD_SA_NOT_FOUND. > > I guess it should delete it. Yes, I think this is actually covered by the 2.25 and 2.25.1. 2.25 says it even better and says you delete the Child SA: A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a request to rekey a Child SA that does not exist. The SA that the initiator attempted to rekey is indicated by the SPI field in the Notify payload, which is copied from the SPI field in the REKEY_SA notification. A peer that receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA (if it still exists) and send a request to create a new Child SA from scratch (if the Child SA does not yet exist). > : 3) Host A has sent CREATE_CHILD_SA and got reply to that from B1, but > : B2 does not know anything about it and host A tries to delete that > : SA. > : > Same section as above: > > If a peer receives a request to close a Child SA > that does not exist, it SHOULD reply without a Delete payload. > > The B2 will never send any traffic to the SA because it doesn't have it. But this will leave A with half-closed SAs. The text in 2.25.1 assumes that the other pair of the SA was deleted because of the exchange collisions, so it does not need to care about the half-closed SAs as there will not be such in that situation. > I don't see anything that prevents working connections. But in some cases there is leftover half-closed SAs which by IKEv2 the other end cannot delete without deleting the whole IKE SA. We might need some way to resolve those. -- kivinen@iki.fi From ynir@checkpoint.com Wed Nov 24 03:23:53 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B75828C182 for ; Wed, 24 Nov 2010 03:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.672 X-Spam-Level: X-Spam-Status: No, score=-8.672 tagged_above=-999 required=5 tests=[AWL=1.927, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9o3ofjFeVKva for ; Wed, 24 Nov 2010 03:23:52 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 3E6CE28C153 for ; Wed, 24 Nov 2010 03:23:52 -0800 (PST) X-CheckPoint: {4CECF295-3-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oAOBOott022103; Wed, 24 Nov 2010 13:24:50 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 24 Nov 2010 13:24:49 +0200 From: Yoav Nir To: "'Tero Kivinen'" , Pekka Riikonen Date: Wed, 24 Nov 2010 13:24:49 +0200 Thread-Topic: [IPsec] HA protocol replay protection Thread-Index: AcuLyVsMJrl1nYHkRhygGDOa2v8ELAAAE2gw Message-ID: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4483@il-ex01.ad.checkpoint.com> References: <4CDC08CF.8030106@gmail.com> <19686.24984.949221.628414@fireball.kivinen.iki.fi> <19691.48233.734358.997141@fireball.kivinen.iki.fi> <19691.55909.326260.368178@fireball.kivinen.iki.fi> <19692.62592.608771.229675@fireball.kivinen.iki.fi> In-Reply-To: <19692.62592.608771.229675@fireball.kivinen.iki.fi> 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 11:23:53 -0000 As a general principle, yes. But the HA extension already assumes that due = to the failover, there is some discrepancy. The easy way out would be to wr= ite a protocol extension that just detects this discrepancy and kills the I= KE SA. But that would mean a lot of IKE SA setups following a fail-over. So in the context of the HA extension, we are willing to live with some uns= ynchronized state, and try to let it take care of itself. So the question = is, if the peer already does not have the IPsec SA, does it add any informa= tion for us to send it a DELETE? Yoav -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of T= ero Kivinen Sent: 24 November 2010 13:18 To: Pekka Riikonen Cc: IPsecme WG Subject: Re: [IPsec] HA protocol replay protection Pekka Riikonen writes: >=20 > On Tue, 23 Nov 2010, Tero Kivinen wrote: > : I think correct way to handle INVALID_SPI is that consider it as same > : as the other end would have sent delete for that his inbound SPI > : listed in the notification, and then send corresponding delete for > : your inbound SPI, which the other end will ignore as specified in the > : 2.25.1: > :=20 > I'm not sure I agree. I think it's reasonable to assume that if you=20 > receive INVALID_SPI notification instead of delete notification is that=20 > the remote end has crashed or there is something else terribly wrong with= =20 > it and that it most likely doesn't have any state for the SA pair. General principle in the IKEv2 is that it is reliable protocol, and the state should not get out of sync. If you are getting INVALID_SPI for SA which you think is valid that means that other end is doing something wrong (for base IKEv2 case). From kivinen@iki.fi Wed Nov 24 03:56:24 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096343A691E for ; Wed, 24 Nov 2010 03:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e07RUFXMmE+u for ; Wed, 24 Nov 2010 03:56:23 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E5FB93A6923 for ; Wed, 24 Nov 2010 03:56:22 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id oAOBvEEK028948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Nov 2010 13:57:14 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id oAOBvDf0011005; Wed, 24 Nov 2010 13:57:13 +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: <19692.64921.816987.559826@fireball.kivinen.iki.fi> Date: Wed, 24 Nov 2010 13:57:13 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4483@il-ex01.ad.checkpoint.com> References: <4CDC08CF.8030106@gmail.com> <19686.24984.949221.628414@fireball.kivinen.iki.fi> <19691.48233.734358.997141@fireball.kivinen.iki.fi> <19691.55909.326260.368178@fireball.kivinen.iki.fi> <19692.62592.608771.229675@fireball.kivinen.iki.fi> <006FEB08D9C6444AB014105C9AEB133F012E6FCD4483@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 1 min Cc: IPsecme WG , Pekka Riikonen Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 11:56:24 -0000 Yoav Nir writes: > As a general principle, yes. But the HA extension already assumes > that due to the failover, there is some discrepancy. The easy way > out would be to write a protocol extension that just detects this > discrepancy and kills the IKE SA. But that would mean a lot of IKE > SA setups following a fail-over. I do not think we need such protocol. > So in the context of the HA extension, we are willing to live with > some unsynchronized state, and try to let it take care of itself. I agree on first step, but I would rather like to see some text explaining how they are taken care of. I do not think we can assume the "problem takes care of itself". > So the question is, if the peer already does not have the IPsec SA, > does it add any information for us to send it a DELETE? In IKEv2 context it is mandatory, but in high availability IKEv2 context we can specify whatever we want, but we need to specify what we want. -- kivinen@iki.fi From zhangdacheng@huawei.com Thu Nov 25 02:00:36 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800E23A6AC0 for ; Thu, 25 Nov 2010 02:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=3.394, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g70K8-CBp5Ey for ; Thu, 25 Nov 2010 02:00:35 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A06463A6AC3 for ; Thu, 25 Nov 2010 02:00:35 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCF00598QH27B@szxga03-in.huawei.com> for ipsec@ietf.org; Thu, 25 Nov 2010 18:00:38 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCF00G1NQH2D8@szxga03-in.huawei.com> for ipsec@ietf.org; Thu, 25 Nov 2010 18:00:38 +0800 (CST) Received: from z00133208z ([10.110.98.41]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCF00CK8QGPMX@szxml06-in.huawei.com> for ipsec@ietf.org; Thu, 25 Nov 2010 18:00:38 +0800 (CST) Date: Thu, 25 Nov 2010 18:00:25 +0800 From: Dacheng Zhang In-reply-to: <19691.56213.969437.881301@fireball.kivinen.iki.fi> To: 'Tero Kivinen' , 'Yaron Sheffer' Message-id: <000001cb8c87$94fa3410$beee9c30$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcuLIealjMngzhl1R02RjYH8Dqx23wBZRAXw References: <4CDC08CF.8030106@gmail.com> <19686.24984.949221.628414@fireball.kivinen.iki.fi> <19691.48233.734358.997141@fireball.kivinen.iki.fi> <4CEBDA72.6040901@gmail.com> <19691.56213.969437.881301@fireball.kivinen.iki.fi> Cc: 'IPsecme WG' , 'Pekka Riikonen' Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 10:00:36 -0000 >> >> Except there is no way to know the value of delta. And if you do not >> know value of delta, then you open yourself to replay attacks if your >> delta was too small. >> >> Having some arbitrary delta, which is impossible to pick properly, >> isn't really solving the problem, it just makes the attacks bit harder >> for the attacker, but it does not remove those attacks. [Dacheng Zhang] Maybe a client can find the largest counter value in the associated child SAs and use it as the delta value. Although this approach is not sophisticated, it can prevent the client selects a delta value which is not big enough. ^_^ --Dacheng >> -- >> kivinen@iki.fi >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Thu Nov 25 02:55:53 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C72A3A6A2D for ; Thu, 25 Nov 2010 02:55:53 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apEQwr9D4qTj for ; Thu, 25 Nov 2010 02:55:52 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 42B473A6893 for ; Thu, 25 Nov 2010 02:55:52 -0800 (PST) Received: by wyb29 with SMTP id 29so757044wyb.31 for ; Thu, 25 Nov 2010 02:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ZP3qbgYkQ9R5HBjPkbnJCWAxZQyDZ1XRJNlIPDbZ8Qs=; b=iV+DehFMZHxK75ffl+DwIOWN3iqwS0yN8LOei5mLOXkInTVr9znYcjKU6KzSYF6EtL L/wv96rgoA5M4/ShpS0Wlf2t40Ro+1KIilGQNmMtrWT9vYXfXICdkijIAYjabOpiU0KU udCrBh4/BlWea336vwAla19+3MQVNtFP0ajYo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=n3owN4kD1XYZsOu0yQXm6TlBArB9HLkSu7mr5dboikZjnZeKLgpp3TQBbLZIErU7KY wazNx4Ix6IoQz2M1fKySvbPxgUhRWFhbhaQiUCwHJn6N5B6xMYqWP8NTTL+sa8RN2ooh kddo5bPK5PsD6aC17Fqq+J4gTi83wDrc5RY7w= Received: by 10.227.132.83 with SMTP id a19mr676450wbt.30.1290682609947; Thu, 25 Nov 2010 02:56:49 -0800 (PST) Received: from [10.0.0.61] ([109.66.245.19]) by mx.google.com with ESMTPS id ga16sm399097wbb.1.2010.11.25.02.56.46 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Nov 2010 02:56:48 -0800 (PST) Message-ID: <4CEE40ED.2060501@gmail.com> Date: Thu, 25 Nov 2010 12:56:45 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Dacheng Zhang References: <4CDC08CF.8030106@gmail.com> <19686.24984.949221.628414@fireball.kivinen.iki.fi> <19691.48233.734358.997141@fireball.kivinen.iki.fi> <4CEBDA72.6040901@gmail.com> <19691.56213.969437.881301@fireball.kivinen.iki.fi> <000001cb8c87$94fa3410$beee9c30$@com> In-Reply-To: <000001cb8c87$94fa3410$beee9c30$@com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: 'IPsecme WG' , 'Pekka Riikonen' , 'Tero Kivinen' Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 10:55:53 -0000 Hi Dacheng, I must be missing something: this discussion was about IKE SA counters (Message ID). I don't see how they can be inferred from Child SA replay counters. The traffic rates are too different. Thanks, Yaron On 11/25/2010 12:00 PM, Dacheng Zhang wrote: >>> >>> Except there is no way to know the value of delta. And if you do not >>> know value of delta, then you open yourself to replay attacks if your >>> delta was too small. >>> >>> Having some arbitrary delta, which is impossible to pick properly, >>> isn't really solving the problem, it just makes the attacks bit harder >>> for the attacker, but it does not remove those attacks. > [Dacheng Zhang] > Maybe a client can find the largest counter value in the associated child > SAs and use it as the delta value. Although this approach is not > sophisticated, it can prevent the client selects a delta value which is not > big enough. ^_^ > > --Dacheng >>> -- >>> kivinen@iki.fi >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec > > From priikone@iki.fi Sun Nov 28 22:35:11 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B72ED3A6BFA for ; Sun, 28 Nov 2010 22:35:11 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38vZFDOWNZ-z for ; Sun, 28 Nov 2010 22:35:10 -0800 (PST) Received: from otaku.Xtrmntr.org (sauna.silcnet.org [IPv6:2001:4118:10:4000::2205]) by core3.amsl.com (Postfix) with ESMTP id 1DE4F3A6BFC for ; Sun, 28 Nov 2010 22:35:09 -0800 (PST) Received: by otaku.Xtrmntr.org (Postfix, from userid 201) id E530648B9; Mon, 29 Nov 2010 07:36:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by otaku.Xtrmntr.org (Postfix) with ESMTP id E33FF48AF; Mon, 29 Nov 2010 07:36:18 +0100 (CET) Date: Mon, 29 Nov 2010 07:36:18 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: Tero Kivinen In-Reply-To: <19692.62592.608771.229675@fireball.kivinen.iki.fi> Message-ID: References: <4CDC08CF.8030106@gmail.com> <19686.24984.949221.628414@fireball.kivinen.iki.fi> <19691.48233.734358.997141@fireball.kivinen.iki.fi> <19691.55909.326260.368178@fireball.kivinen.iki.fi> <19692.62592.608771.229675@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: IPsecme WG Subject: Re: [IPsec] HA protocol replay protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 06:35:12 -0000 : > The text you quote are from the section dealing with delete : > notifications. But since the RFC doesn't specify what to do with : > INVALID_SPI I think this is a _reasonable_ assumption, especially : > since this is what is says about it: : : It is better not to assume people do things same way unless explictly : specified, which is why I think the new high availibility protocol : needs to have text explaining these situations. I do not really care : which way the text is written as long as it is there and tells how to : handle these situations. : I agree, we want the text to the draft. : > : B2 does not know anything about it and host A tries to send traffic : > : to that SA. : > : : > INVALID_SPI fixes (assuming we agree its handling). Delete notification : > fixes too but will result into half-closed SA for the A's inbound SA. The : > host A will never receive any traffic to that SA. : : I agree on that. Adding text for INVALID_SPI handling would most : likely be best. : Good, I agree on that too, INVALID_SPI is best way to go. : > I don't see anything that prevents working connections. : : But in some cases there is leftover half-closed SAs which by IKEv2 the : other end cannot delete without deleting the whole IKE SA. We might : need some way to resolve those. : Yeah, one or two cases may lead to this. I guess it wouldn't be so terrible to do what RFC says and just delete the IKE SA in these cases. Pekka From kent@bbn.com Tue Nov 30 10:29:17 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 211C228C166 for ; Tue, 30 Nov 2010 10:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.361 X-Spam-Level: X-Spam-Status: No, score=-102.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnUOKAUBvVJ8 for ; Tue, 30 Nov 2010 10:29:16 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6859328C0EB for ; Tue, 30 Nov 2010 10:29:16 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:34083 helo=[10.84.131.129]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PNUyC-000558-0O; Tue, 30 Nov 2010 13:30:28 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <903D13EA90218E43BA0881BC8B569C7D0F8B8FB7B1@BLRINMSMBX01.bglrodc.lntinfote ch.com> References: <903D13EA90218E43BA0881BC8B569C7D0F8B8FB7B1@BLRINMSMBX01.bglrodc.lntinfote ch.com> Date: Tue, 30 Nov 2010 11:50:45 -0500 To: Anil Maguluri From: Stephen Kent Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Clarification regarding AH Header Length X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 18:29:17 -0000 At 10:40 AM +0530 11/23/10, Anil Maguluri wrote: >Content-Language: en-US >Content-Type: multipart/alternative; >=20 > boundary=3D"_000_903D13EA90218E43BA0881BC8B569C7D0F8B8FB7B1BLRINMSMBX01b_" > >Hi All, > >Please clarify me the below query. > >=E8 When AH Header Length becomes zero (in which scenario)? >=E8 If the length is zero, means no SN and AH Data=20 >wont be available in the packet. > >Regards, >Anil Kumar Maguluri If AH is present, it will not have a 0 length. Steve