From ynir@checkpoint.com Thu Dec 2 02:33: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 A8BE23A68FD for ; Thu, 2 Dec 2010 02:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.333 X-Spam-Level: X-Spam-Status: No, score=-8.333 tagged_above=-999 required=5 tests=[AWL=0.777, BAYES_05=-1.11, 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 KOydnqx4almc for ; Thu, 2 Dec 2010 02:33:04 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 723CC3A68EC for ; Thu, 2 Dec 2010 02:33:04 -0800 (PST) X-CheckPoint: {4CF7762A-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 oB2AYIaR010755 for ; Thu, 2 Dec 2010 12:34:18 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 2 Dec 2010 12:34:18 +0200 From: Yoav Nir To: IPsecme WG Date: Thu, 2 Dec 2010 12:34:15 +0200 Thread-Topic: Issue #199 - Section 7.4 is mostly wrong Thread-Index: AcuSDHiEgt2oBfkGQVS6xlLm9H/fJQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Issue #199 - Section 7.4 is mostly wrong 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, 02 Dec 2010 10:33:05 -0000 Hi all This issue is about some of the wording of section 7.4. I don't agree that = this is mostly wrong, but I think the group's energies are better spent els= ewhere. Section 7, in its entirety is about alternative solutions that were= not adopted. I think we can either delete the whole section, or else move it to an appen= dix. What do others think? Yoav= From wierbows@us.ibm.com Thu Dec 2 07:05: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 C7A2A28C140; Thu, 2 Dec 2010 07:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ioU4E8v9pTD; Thu, 2 Dec 2010 07:05:51 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by core3.amsl.com (Postfix) with ESMTP id 4DD6528C0E3; Thu, 2 Dec 2010 07:05:51 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id oB2EnOPv002707; Thu, 2 Dec 2010 09:49:24 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id DD0B74DE803D; Thu, 2 Dec 2010 10:05:18 -0500 (EST) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oB2F6w9h126512; Thu, 2 Dec 2010 10:06:58 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oB2F6wR7027813; Thu, 2 Dec 2010 13:06:58 -0200 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id oB2F6qEU027241; Thu, 2 Dec 2010 13:06:52 -0200 In-Reply-To: References: X-KeepSent: F0846FF0:264B0436-852577ED:00510F51; type=4; name=$KeepSent To: Yoav Nir X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 Message-ID: From: David Wierbowski Date: Thu, 2 Dec 2010 10:06:49 -0500 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 12/02/2010 10:06:51 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Content-Scanned: Fidelis XPS MAILER Cc: IPsecme WG , ipsec-bounces@ietf.org Subject: Re: [IPsec] Issue #199 - Section 7.4 is mostly wrong 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, 02 Dec 2010 15:05:53 -0000 Yoav, I think preserving the history is worthwhile. I'm fine with moving section 7 to an appendix. With that said Tero will still object to the text that would become A1.4 (currently 7.4). The text in Section 7.4 represents our opinion which is not the same as his. I think the text should be modified to acknowledge that some implementations may reduce their timeout due to INVALID_SPI or INVALID_IKE_SPI, but we feel this still results in an unnecessary delay that could be eliminated with use of QCD tokens. I suggest the following replacement text: Some implementations require fewer retransmissions over a shorter period of time for cases of liveness check started because of an INVALID_SPI or INVALID_IKE_SPI notification. We believe that the default retransmission policy should represent a good balance between the need for a timely discovery of a dead peer, and a low probability of false detection. We expect the policy to be set to take the shortest time such that this probability achieves a certain target. Therefore, we believe that reducing the elapsed time and retransmission count may create an unacceptably high probability of false detection, and this can be triggered by a single INVALID_IKE_SPI notification. Additionally, even if the retransmission policy is reduced to, say, one minute, it is still a very noticeable delay from a human perspective, from the time that the gateway has come up (i.e. is able to respond with an INVALID_SPI or INVALID_IKE_SPI notification) and until the tunnels are active, or from the time the backup gateway has taken over until the tunnels are active. The use of QCD tokens can reduce this delay. Dave Wierbowski From: Yoav Nir To: IPsecme WG Date: 12/02/2010 05:34 AM Subject: [IPsec] Issue #199 - Section 7.4 is mostly wrong Sent by: ipsec-bounces@ietf.org Hi all This issue is about some of the wording of section 7.4. I don't agree that this is mostly wrong, but I think the group's energies are better spent elsewhere. Section 7, in its entirety is about alternative solutions that were not adopted. I think we can either delete the whole section, or else move it to an appendix. What do others think? Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From priikone@iki.fi Thu Dec 2 21:47:06 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 C3E703A6A6A for ; Thu, 2 Dec 2010 21:47:06 -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 932J405bdu22 for ; Thu, 2 Dec 2010 21:47:05 -0800 (PST) Received: from otaku.Xtrmntr.org (sauna.silcnet.org [IPv6:2001:4118:10:4000::2205]) by core3.amsl.com (Postfix) with ESMTP id 0EF1F3A6A69 for ; Thu, 2 Dec 2010 21:47:04 -0800 (PST) Received: by otaku.Xtrmntr.org (Postfix, from userid 201) id D7AA648AF; Fri, 3 Dec 2010 06:48:26 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by otaku.Xtrmntr.org (Postfix) with ESMTP id D1F4F488E; Fri, 3 Dec 2010 06:48:26 +0100 (CET) Date: Fri, 3 Dec 2010 06:48:26 +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: Fri, 03 Dec 2010 05:47:06 -0000 On Tue, 23 Nov 2010, Tero Kivinen wrote: : > 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. : : > 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. : I'd like to return to this failover counter. It's the single issue in the protocol which I don't like. The reasons are, first, that it makes an assumption how clustering and sync has been implemented, that is this value has to be synced in the cluster and the protocol cannot work without it, and second, that the protocol itself becomes vulnerable to the very issues it tries to combat, namely the fact that sync messages can be dropped. Consider for example three node cluster where node 1 fails. Node 2 increments the failover counter but fails to sync it to node 3 (the packet is dropped or node 2 fails immediately itself). Node 3 now hasn't the updated failover counter and will create a request that is effectively a replay. The draft has the following text: In case multiple successive failover events and sync request getting lost, the failover count value at peer will not be updated and new standby member will become active with incremented failover count value. So, peer can receive valid failover count value which is not just incremented by 1 in case of multiple failover. Accepting incremented failover count within a range is allowed and increases interoperability. Which is vague, and I don't even completely understand what it tries to tell here. In case of multiple failovers the failover counter might *not* be incremented at all because the sync may have been dropped. I think the protocol should not have a feature that depends on the sync itself working. That's the very issue it tries to fix in HA, the fact that IKE SA message IDs in failover may be in desync. The failover counter may be in desync as well. And if implementations are expected to be lax about the value (due to the issues listed above) then it doesn't really provide replay protection either. I think we should try to find alternative methods to combat the replay of requests. Here's some thoughts: o Some kind of expiration timestamp to requests. Not sure how easy or practical it would be to implement but would not require any sync expectations. o Request could always propose message_id + delta, so that if it is replayed it's already too old and can be detected. This is something that Yaron suggested as well, I believe. It does have some issues, some of them already discussed earlier. Some other way? Pekka From kivinen@iki.fi Fri Dec 3 05:21: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 1DBA228C0D9 for ; Fri, 3 Dec 2010 05:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 AXxIXBnOtgPO for ; Fri, 3 Dec 2010 05:21:05 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 4633E28C0E6 for ; Fri, 3 Dec 2010 05:21:04 -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 oB3DMIvr029265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Dec 2010 15:22:18 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id oB3DMIXl029995; Fri, 3 Dec 2010 15:22:18 +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: <19704.61193.951396.469620@fireball.kivinen.iki.fi> Date: Fri, 3 Dec 2010 15:22:17 +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: 26 min X-Total-Time: 13 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: Fri, 03 Dec 2010 13:21:07 -0000 Pekka Riikonen writes: > I'd like to return to this failover counter. It's the single issue in the > protocol which I don't like. The reasons are, first, that it makes an > assumption how clustering and sync has been implemented, that is this > value has to be synced in the cluster and the protocol cannot work without > it, and second, that the protocol itself becomes vulnerable to the very > issues it tries to combat, namely the fact that sync messages can be > dropped. Depends how we define failover counter. If we define so it is monotonously increasing counter which can skip forward there are ways to do it without syncing the information. As most of the sync protocols already have either timestamps or some kind of message ids using those as failover counter would work. I.e. in the simplest case just use last failover time as failover counter. There is no reason for failover counter to increment by one for every failover, its value just needs to be bigger than the previous failover counter so we can detect whether this is old failover message or whether it is something we haven't seen before. > Consider for example three node cluster where node 1 fails. Node 2 > increments the failover counter but fails to sync it to node 3 (the packet > is dropped or node 2 fails immediately itself). Node 3 now hasn't the > updated failover counter and will create a request that is effectively a > replay. So the node 2 should first agree that it really is the one who is going to take care of the failing node 1 traffic, thus it needs to communiate with node 3 and agree on that (to prevent both node 2 and node 3 acting as failover hosts). During this communication it can also sync the failover counter. Also if node 3 just detects that node 2 crashed by snooping the traffic, then it can also snoop the IKEv2 message ID sync messages and get the failover counter from there (it do have the keying material to decrypt the IKEv2 messages if it is going to be acting as failover node). > The draft has the following text: > > In case multiple successive failover events and sync request getting > lost, the failover count value at peer will not be updated and new > standby member will become active with incremented failover count > value. So, peer can receive valid failover count value which is not > just incremented by 1 in case of multiple failover. Accepting > incremented failover count within a range is allowed and increases > interoperability. > > Which is vague, and I don't even completely understand what it tries to > tell here. In case of multiple failovers the failover counter might *not* > be incremented at all because the sync may have been dropped. I think that text tries to say that as the node 2 might have synced with node 3, but it might be that it failed before it actually managed to send out IKEV2_MESSAGE_ID_SYNC message, thus other end never knows that node 2 was active at all, and the first thing they see is the message from node 3, where the failover counter is incremented twice. I think the current text should be clear that failover counter can be incremented by any number, and message is accepted if failover counter is larger than any previous failover counter node has seen. This kind of text would allow using for example timestamp instead of failover counters, on those clusters where they do have good enough synced clocks. -- kivinen@iki.fi From priikone@iki.fi Fri Dec 3 11:45:56 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 A46563A6996 for ; Fri, 3 Dec 2010 11:45:56 -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 flPwyG7bWhdx for ; Fri, 3 Dec 2010 11:45:55 -0800 (PST) Received: from otaku.Xtrmntr.org (sauna.silcnet.org [IPv6:2001:4118:10:4000::2205]) by core3.amsl.com (Postfix) with ESMTP id 083E23A6995 for ; Fri, 3 Dec 2010 11:45:55 -0800 (PST) Received: by otaku.Xtrmntr.org (Postfix, from userid 201) id 5A45548AE; Fri, 3 Dec 2010 20:47:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by otaku.Xtrmntr.org (Postfix) with ESMTP id 58829488E; Fri, 3 Dec 2010 20:47:20 +0100 (CET) Date: Fri, 3 Dec 2010 20:47:19 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: Tero Kivinen In-Reply-To: <19704.61193.951396.469620@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> <19704.61193.951396.469620@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: Fri, 03 Dec 2010 19:45:56 -0000 On Fri, 3 Dec 2010, Tero Kivinen wrote: : Depends how we define failover counter. If we define so it is : monotonously increasing counter which can skip forward there are ways : to do it without syncing the information. As most of the sync : protocols already have either timestamps or some kind of message ids : using those as failover counter would work. I.e. in the simplest case : just use last failover time as failover counter. : : There is no reason for failover counter to increment by one for every : failover, its value just needs to be bigger than the previous failover : counter so we can detect whether this is old failover message or : whether it is something we haven't seen before. : That's a good point, but there's still the receiving end that has to consistently be able to determine whether given failover counter is replay or not. Let say, both ends are clusters, this means that the receiving end has to somehow sync the information between its nodes. Otherwise its nodes might not know which value is old and which isn't (for example due to failover or load balancing). Unless, of course, this is somekind of timestamp (an actual clock or something like that) that can be consistently verified also at the receiving end without syncing. On the other hand, I do say that this is better than what it is now in the draft; even if the receiving end has to sync it and fails to do so properly the protocol still works, it just opens a possibilty for a replay attack. : > Consider for example three node cluster where node 1 fails. Node 2 : > increments the failover counter but fails to sync it to node 3 (the packet : > is dropped or node 2 fails immediately itself). Node 3 now hasn't the : > updated failover counter and will create a request that is effectively a : > replay. : : So the node 2 should first agree that it really is the one who is : going to take care of the failing node 1 traffic, thus it needs to : communiate with node 3 and agree on that (to prevent both node 2 and : node 3 acting as failover hosts). During this communication it can : also sync the failover counter. : Here it usually would be determined by the IKE SAs that were "owned" by node 1 that are now owned by node 2. It's quite possible, by the way, that both node 2 and node 3 can now "own" some of node 1's IKE SAs, and have to perform the HA protocol for those independently. This would be a cluster were all nodes are "online" and one of them fails. The case described in the draft is a hot stanbdy cluster case where only one node is online and others are standby until the online node fails. This would imply that the standby node that becomes online after failover gets all of the SAs of the failed node. All this is implementation specific. Though, in my opinion the protocol should be able to work in all scenarios, including in one were multiple nodes independently perform HA protocol for their IKE SAs (a case not described in the draft currently. This would change the original scope of the draft from hot standby cluster case to include online cluster case were load balancing change (failover, online/offline transition or other artificial load balancing change) re-balances SAs among multiple online nodes). : I think the current text should be clear that failover counter can be : incremented by any number, and message is accepted if failover counter : is larger than any previous failover counter node has seen. : : This kind of text would allow using for example timestamp instead of : failover counters, on those clusters where they do have good enough : synced clocks. : I agree, but it needs to be carefully defined so that the receiver can actually verify its validity in case it's a cluster. Pekka From ynir@checkpoint.com Mon Dec 13 04:34: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 BF1C33A6DAC for ; Mon, 13 Dec 2010 04:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.577 X-Spam-Level: X-Spam-Status: No, score=-9.577 tagged_above=-999 required=5 tests=[AWL=1.022, 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 SN9dF-yqb7q0 for ; Mon, 13 Dec 2010 04:34:51 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 9E1E93A6DA5 for ; Mon, 13 Dec 2010 04:34:50 -0800 (PST) X-CheckPoint: {4D06134B-E-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 oBDCaRJV002489 for ; Mon, 13 Dec 2010 14:36:27 +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, 13 Dec 2010 14:36:26 +0200 From: Yoav Nir To: "ipsec@ietf.org" Date: Mon, 13 Dec 2010 14:36:28 +0200 Thread-Topic: QCD applicability (issues #198 and #201) Thread-Index: AcuawluXpXO6eCZ2RfSycw+GWQbAAw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] QCD applicability (issues #198 and #201) 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, 13 Dec 2010 12:34:51 -0000 Hi all An issue that has come up on this mailing list, and also in Beijing, is wha= t implementations should assume either of the two roles (token maker and to= ken taker). The current text is in section 9.1, and is summarized as follows: o For remote-access clients it makes sense to implement the token taker role. o For remote-access gateways it makes sense to implement the token maker role. 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. o It is perfectly valid to implement both roles in any case, for example when using a single library or a single gateway to perform several roles. Tero's comments were that the interdomain case (bullet #3) was not interest= ing (issue #201), because in inter-domain VPN, both sides can start an Init= ial exchange, or that the initiator and responder should only be taker and = maker respectively (issue #198). While I think few would argue that a remote access client needs to be a tok= en maker, there were some people (including all document authors) who argue= d that QCD is useful for inter-domain, and that it shouldn't matter who was= the original initiator, because over the life of an SA traffic might shift= to be initiated on the other side. I think it's time to resolve this. Do we leave this as-is, or do we cut dow= n the applicability. Yoav= From smoonen@us.ibm.com Mon Dec 13 06:07:28 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 E354928C0E7; Mon, 13 Dec 2010 06:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.857 X-Spam-Level: X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] 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 qbPCWFb1z2yz; Mon, 13 Dec 2010 06:07:27 -0800 (PST) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id 4C2EB28C0E3; Mon, 13 Dec 2010 06:07:27 -0800 (PST) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e36.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id oBDE4G6h004382; Mon, 13 Dec 2010 07:04:16 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oBDE8fdb101280; Mon, 13 Dec 2010 07:08:45 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oBDE8f0g017878; Mon, 13 Dec 2010 07:08:41 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id oBDE8ex3017865; Mon, 13 Dec 2010 07:08:40 -0700 In-Reply-To: References: X-KeepSent: 7DAC2710:12934D08-852577F8:004DA018; type=4; name=$KeepSent To: Yoav Nir X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Scott C Moonen Date: Mon, 13 Dec 2010 09:08:28 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 12/13/2010 07:08:40 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBFD6BDFDE26888f9e8a93df938690918c0ABBFD6BDFDE2688" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] QCD applicability (issues #198 and #201) 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, 13 Dec 2010 14:07:29 -0000 --0__=0ABBFD6BDFDE26888f9e8a93df938690918c0ABBFD6BDFDE2688 Content-type: multipart/alternative; Boundary="1__=0ABBFD6BDFDE26888f9e8a93df938690918c0ABBFD6BDFDE2688" --1__=0ABBFD6BDFDE26888f9e8a93df938690918c0ABBFD6BDFDE2688 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable +1 for leaving it as-is. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Yoav Nir To: "ipsec@ietf.org" Date: 12/13/2010 07:36 AM Subject: [IPsec] QCD applicability (issues #198 and #201) Sent by: ipsec-bounces@ietf.org Hi all An issue that has come up on this mailing list, and also in Beijing, is= what implementations should assume either of the two roles (token maker= and token taker). The current text is in section 9.1, and is summarized as follows: o For remote-access clients it makes sense to implement the token taker role. o For remote-access gateways it makes sense to implement the token maker role. 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. o It is perfectly valid to implement both roles in any case, for example when using a single library or a single gateway to perfor= m several roles. Tero's comments were that the interdomain case (bullet #3) was not interesting (issue #201), because in inter-domain VPN, both sides can s= tart an Initial exchange, or that the initiator and responder should only be= taker and maker respectively (issue #198). While I think few would argue that a remote access client needs to be a= token maker, there were some people (including all document authors) wh= o argued that QCD is useful for inter-domain, and that it shouldn't matte= r who was the original initiator, because over the life of an SA traffic might shift to be initiated on the other side. I think it's time to resolve this. Do we leave this as-is, or do we cut= down the applicability. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBFD6BDFDE26888f9e8a93df938690918c0ABBFD6BDFDE2688 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

+1 for leaving it as-is.

Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/= in/smoonen

3D"InactiveYoav Nir ---12/13/20= 10 07:36:47 AM---Hi all An issue that has come up on this mailing list,= and also in Beijing, is what implementations

From: Yoav N= ir <ynir@checkpoint.com>
To: "ip= sec@ietf.org" <ipsec@ietf.org>
Date: 12/13/= 2010 07:36 AM
Subject: [IP= sec] QCD applicability (issues #198 and #201)
Sent by: ips= ec-bounces@ietf.org




Hi all

An issue that has come up on this mailing list, and also in Beijing, is= what implementations should assume either of the two roles (token make= r and token taker).

The current text is in section 9.1, and is summarized as follows:
  o  For remote-access clients it makes sense to implement t= he token
     taker role.
  o  For remote-access gateways it makes sense to implement = the token
     maker role.
  o  For inter-domain VPN gateway it makes sense to implemen= t both
     roles, because it can't be known in advance where = the traffic
     originates.
  o  It is perfectly valid to implement both roles in any ca= se, for
     example when using a single library or a single ga= teway to perform
     several roles.

Tero's comments were that the interdomain case (bullet #3) was not inte= resting (issue #201), because in inter-domain VPN, both sides can start= an Initial exchange, or that the initiator and responder should only b= e taker and maker respectively (issue #198).

While I think few would argue that a remote access client needs to be a= token maker, there were some people (including all document authors) w= ho argued that QCD is useful for inter-domain, and that it shouldn't ma= tter who was the original initiator, because over the life of an SA tra= ffic might shift to be initiated on the other side.

I think it's time to resolve this. Do we leave this as-is, or do we cut= down the applicability.

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

= --1__=0ABBFD6BDFDE26888f9e8a93df938690918c0ABBFD6BDFDE2688-- --0__=0ABBFD6BDFDE26888f9e8a93df938690918c0ABBFD6BDFDE2688 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFD6BDFDE26888f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFD6BDFDE26888f9e8a93df938690918c0ABBFD6BDFDE2688-- From yaronf.ietf@gmail.com Mon Dec 13 07:38:20 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 8BE103A6DD2 for ; Mon, 13 Dec 2010 07:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 3O-Dz9TW8H3U for ; Mon, 13 Dec 2010 07:38:19 -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 2D8CD3A6CB5 for ; Mon, 13 Dec 2010 07:38:19 -0800 (PST) Received: by wyf23 with SMTP id 23so6140554wyf.31 for ; Mon, 13 Dec 2010 07:39:56 -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=yumJO3UeSOsZ5K26YWnEXl0v+VcfmYhzvPS+9HzRUoY=; b=NuYhxylWI3mLPjRqVSyYHDpOdVP1AVqU6FkFGOhn+MlDOqCiJVlz4WtzXMWEwDjzjD ct6n5VaEo5uHAhfjJ+Fo1ae4+suhooBBZv8jJ8o7Upnn4uZ7gFgDwV02uvPeg4P563tS 3NVG3jdjJRAd7Ed9lRoR8lhHxX56mvSmfniLQ= 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=dPr59T+GFo72iMhJZ8zTKZ0gc/cW4ZKjehDCk6Pi8Ov9vslxXK4xJ9qaXuFl9S6SGA wVm2qUWporp5lE8JGGASlT/ke0wTC3LBWNbBSB8OTeJiTGQMrgvOEpz/v048adaaathp r1J5pX7W8TeNVvCynfvWLxSY69BBCM3DrPPVg= Received: by 10.227.129.69 with SMTP id n5mr1747722wbs.136.1292254796756; Mon, 13 Dec 2010 07:39:56 -0800 (PST) Received: from [10.0.0.1] (bzq-79-176-46-32.red.bezeqint.net [79.176.46.32]) by mx.google.com with ESMTPS id m10sm4495354wbc.10.2010.12.13.07.39.52 (version=SSLv3 cipher=RC4-MD5); Mon, 13 Dec 2010 07:39:55 -0800 (PST) Message-ID: <4D063E46.1000202@gmail.com> Date: Mon, 13 Dec 2010 17:39:50 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Scott C Moonen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] QCD applicability (issues #198 and #201) 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, 13 Dec 2010 15:38:20 -0000 +1, both peers should be able to assume one or both roles. Thanks, Yaron On 12/13/2010 04:08 PM, Scott C Moonen wrote: > +1 for leaving it as-is. > > Scott Moonen (smoonen@us.ibm.com) > z/OS Communications Server TCP/IP Development > http://www.linkedin.com/in/smoonen > > Inactive hide details for Yoav Nir ---12/13/2010 07:36:47 AM---Hi all An > issue that has come up on this mailing list, and also Yoav Nir > ---12/13/2010 07:36:47 AM---Hi all An issue that has come up on this > mailing list, and also in Beijing, is what implementations > > From: Yoav Nir > To: "ipsec@ietf.org" > Date: 12/13/2010 07:36 AM > Subject: [IPsec] QCD applicability (issues #198 and #201) > Sent by: ipsec-bounces@ietf.org > > ------------------------------------------------------------------------ > > > > Hi all > > An issue that has come up on this mailing list, and also in Beijing, is > what implementations should assume either of the two roles (token maker > and token taker). > > The current text is in section 9.1, and is summarized as follows: > o For remote-access clients it makes sense to implement the token > taker role. > o For remote-access gateways it makes sense to implement the token > maker role. > 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. > o It is perfectly valid to implement both roles in any case, for > example when using a single library or a single gateway to perform > several roles. > > Tero's comments were that the interdomain case (bullet #3) was not > interesting (issue #201), because in inter-domain VPN, both sides can > start an Initial exchange, or that the initiator and responder should > only be taker and maker respectively (issue #198). > > While I think few would argue that a remote access client needs to be a > token maker, there were some people (including all document authors) who > argued that QCD is useful for inter-domain, and that it shouldn't matter > who was the original initiator, because over the life of an SA traffic > might shift to be initiated on the other side. > > I think it's time to resolve this. Do we leave this as-is, or do we cut > down the applicability. > > Yoav > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Tue Dec 14 21:48: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 02ED73A63D2 for ; Tue, 14 Dec 2010 21:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 3B9oIP4DRkbw for ; Tue, 14 Dec 2010 21:48:13 -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 8DE1C3A6FD7 for ; Tue, 14 Dec 2010 21:48:13 -0800 (PST) Received: by wyf23 with SMTP id 23so1167363wyf.31 for ; Tue, 14 Dec 2010 21:49:54 -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=6cRPyqE2EtF/SkPftoBaEVr/9rnGCqI6HAlsvAKgCjM=; b=DF9sIpuu0ILqE2Cuct8CHYBwERogqrB3r9H7TInCSKJvKTT++DRrx9pFxB0EXePcA0 e9+cF+dg7yHZbgEg357kcznnBSSgQOt/cyyFLMNkds/8+UqgKIuxSQt2M/XrEG+TNRDp TK/Z0Xfm5ryF7j4nL2iXu0ZMDW614ozRYSNug= 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=wfmcVLWfA2BYWRm0btLL1gu56AL/1X/DPoJwsvis7yWges+8lTkPrba0TrJGxs5l0P cV/kDOTK22Up6gFt+i6LHwG7qUwWuRSfCxjjkzjkbN7a8GTwx932i1yKr+/n08qeDBQY 0ov7/lR8+i7GwpOW7HTvhe+/t7r9Ru4AfIW/I= Received: by 10.216.173.147 with SMTP id v19mr7933516wel.102.1292392194337; Tue, 14 Dec 2010 21:49:54 -0800 (PST) Received: from [10.0.0.1] (bzq-79-176-46-32.red.bezeqint.net [79.176.46.32]) by mx.google.com with ESMTPS id n3sm640243wer.6.2010.12.14.21.49.52 (version=SSLv3 cipher=RC4-MD5); Tue, 14 Dec 2010 21:49:53 -0800 (PST) Message-ID: <4D0856FE.7070703@gmail.com> Date: Wed, 15 Dec 2010 07:49:50 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] FBI Alleged To Have Backdoored OpenBSD's IPSEC Stack - Slashdot 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, 15 Dec 2010 05:48:15 -0000 Of obvious interest to this list: http://bsd.slashdot.org/story/10/12/15/004235/FBI-Alleged-To-Have-Backdoored-OpenBSDs-IPSEC-Stack?from=rss Please do NOT reply to this list unless you have concrete information about this. Thanks, Yaron From kivinen@iki.fi Wed Dec 15 07:35:13 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 6E98028C0D0 for ; Wed, 15 Dec 2010 07:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 21r8n91nPAFz for ; Wed, 15 Dec 2010 07:35:12 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B99443A7063 for ; Wed, 15 Dec 2010 07:35:11 -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 oBFFagoA000033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Dec 2010 17:36:43 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id oBFFagGq015843; Wed, 15 Dec 2010 17:36:42 +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: <19720.57482.5670.514840@fireball.kivinen.iki.fi> Date: Wed, 15 Dec 2010 17:36:42 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 9 min Cc: "ipsec@ietf.org" Subject: [IPsec] QCD applicability (issues #198 and #201) 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, 15 Dec 2010 15:35:13 -0000 Yoav Nir writes: > I think it's time to resolve this. Do we leave this as-is, or do we > cut down the applicability. I am in favor of making the protocol simplier to implement and especially much simplier to test, and restrict the token taker and token maker roles to initiator and responder respectively. In site to site VPN case there are more efficient methods for recovery which are faster than QCD and which are already allowed in IKEv2 specification and do not require special handling from the other end. I have explained those in my previous emails: http://www.ietf.org/mail-archive/web/ipsec/current/msg06573.html http://www.ietf.org/mail-archive/web/ipsec/current/msg06579.html -- kivinen@iki.fi From paul.hoffman@vpnc.org Thu Dec 16 12:14:45 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 069503A6934 for ; Thu, 16 Dec 2010 12:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.363 X-Spam-Level: X-Spam-Status: No, score=-100.363 tagged_above=-999 required=5 tests=[AWL=-0.731, BAYES_40=-0.185, 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 1GhoFy8kg3Q4 for ; Thu, 16 Dec 2010 12:14:44 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 5CC7E3A6924 for ; Thu, 16 Dec 2010 12:14:44 -0800 (PST) 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 oBGKGSoP055053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Dec 2010 13:16:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 16 Dec 2010 12:16:27 -0800 To: "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] QCD applicability (issues #198 and #201) 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, 16 Dec 2010 20:14:45 -0000 We have heard very few comments on this thread, and yet it is an important one. --Paul Hoffman, Director --VPN Consortium From gpoothia@microsoft.com Fri Dec 17 10:03: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 298123A694F for ; Fri, 17 Dec 2010 10:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ju7zZItdh-Yw for ; Fri, 17 Dec 2010 10:03:21 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 0C4D63A68EB for ; Fri, 17 Dec 2010 10:03:20 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 17 Dec 2010 10:05:08 -0800 Received: from TK5EX14MBXC116.redmond.corp.microsoft.com ([169.254.7.144]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0255.003; Fri, 17 Dec 2010 10:05:07 -0800 From: Gaurav Poothia To: "ipsec@ietf.org" Thread-Topic: Question about DH retry for IKEv2 Thread-Index: AcueE2fY8xVTTn24QwWyMbvbEVsW1g== Date: Fri, 17 Dec 2010 18:05:07 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_B69601AD18064F4BBA2D61CA82AEAFA92817EF8BTK5EX14MBXC116r_" MIME-Version: 1.0 Cc: Brian Swander , Gabriel Montenegro Subject: [IPsec] Question about DH retry for 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: Fri, 17 Dec 2010 18:03:24 -0000 --_000_B69601AD18064F4BBA2D61CA82AEAFA92817EF8BTK5EX14MBXC116r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Re: Part of RFC 5996 Sec 1.2 that talks about DH retry in the case initiato= r guesses the wrong DH group in SA INIT It's not clear to me whether the expectation is for the second SA INIT att= empt (this time with the DH group hinted at by peer) can start afresh with = a new IKE cookie pair (message ID 1) OR If it must retain the existing cookie pair (message ID 2) AFAICT either way is acceptable since both achieve the same end. The former= seems slightly easier. Pls correct me though if one approach is strictly the right way. If so then= why. Thanks --_000_B69601AD18064F4BBA2D61CA82AEAFA92817EF8BTK5EX14MBXC116r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Re: Part of RFC 5996 Sec 1.2 that talks about DH = retry in the case initiator guesses the wrong DH group in SA INIT

 

It’s not clear to me whether the expectation i= s for the second  SA INIT attempt (this time with the DH group hinted = at by peer) can start afresh with a new IKE cookie pair (message ID 1)=

OR

If it must retain the existing cookie pair (message = ID 2)

 

AFAICT either way is acceptable since both achieve t= he same end. The former seems slightly easier.

Pls correct me though if one approach is strictly th= e right way. If so then why.

 

Thanks

--_000_B69601AD18064F4BBA2D61CA82AEAFA92817EF8BTK5EX14MBXC116r_-- From wenrongbupt@gmail.com Sat Dec 18 05:27: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 16C6B3A6A4E for ; Sat, 18 Dec 2010 05:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=1.192, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-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 9t0N6JE-RDZY for ; Sat, 18 Dec 2010 05:27:30 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 2075B3A6A48 for ; Sat, 18 Dec 2010 05:27:30 -0800 (PST) Received: by yxt33 with SMTP id 33so757589yxt.31 for ; Sat, 18 Dec 2010 05:29:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type; bh=7Nk/RwICLDpIc5z2cpJBy/jjwPGekZWbJ4qpuqRxQFY=; b=OhcQRRCXv8tbO38r0yf1PE4CjNZLPw2ZAdI2clOopHJyT2vIwmaOITjWU3OcUPqFM+ yR/FNqTUiizLv5LCsmMRPmNZMzXD55oDGEytUlp8NmOt2/9CBO0hVA2JaA3DCYYNvN1J oEzEy5z+QohYviPCo9+XWo+cFiiZFz5GEWb18= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type; b=Mlhmwsxk/fLo74tFqvAxZu10GQ4DbhnNZE10WTyKdU0ZMp+ud5MmToD/Qyjz2wplxH NxJTrX59iE5A3JfBr9MAF5Ps/HvO3Po/JLLPm4OXh5nftbfnKU8XKccv9H8ZjN/QIU6C VRgRIVunHPb6sn4448HHtLfVjpoamZr2lBbIc= Received: by 10.151.113.9 with SMTP id q9mr4283200ybm.52.1292678959092; Sat, 18 Dec 2010 05:29:19 -0800 (PST) Received: from bupt-wenrong ([118.229.168.29]) by mx.google.com with ESMTPS id l4sm842743yhl.21.2010.12.18.05.29.16 (version=SSLv3 cipher=RC4-MD5); Sat, 18 Dec 2010 05:29:18 -0800 (PST) Date: Sat, 18 Dec 2010 21:29:14 +0800 From: "wenrongbupt" To: "ipsec" Message-ID: <201012182129109067966@gmail.com> X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon460500727033_=====" Subject: [IPsec] SA in the kernel's SADB is how to store? 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, 18 Dec 2010 13:27:33 -0000 This is a multi-part message in MIME format. --=====003_Dragon460500727033_===== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I am a new guy.I want to know the SA in the kernel's SADB is how to store? And,I also want to know the ike daemon(pluto or racoon)is how to write the SA to the SADB? Recently,I am reading the sourcecode of pluto,but I don't found the interface,which to finish write the SA to the SADB. So,I need your help.If you can help me,please send the mail to wenrongbupt@gmail.com. For your letter, I was very grateful .Thank your very much. Best Regards Vincent 2010-12-18 wenrongbupt --=====003_Dragon460500727033_===== Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
Hello，
I am a new guy.I want to know the SA in the kernel's SADB is how to store?
 
And,I also want to know the ike daemon(pluto or racoon)is how to write the SA to the SADB?
 
Recently,I am reading the sourcecode of pluto,but I don't found the interface,which to finish write the SA to the SADB.
 
So,I need your help.If you can help me,please send the mail to wenrongbupt@gmail.com.
 
For your letter, I was very grateful .Thank your very much.
 
 
Best Regards
Vincent
 
 
2010-12-18
wenrongbupt
--=====003_Dragon460500727033_=====-- From ynir@checkpoint.com Sat Dec 18 08:09: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 ED5893A6B02 for ; Sat, 18 Dec 2010 08:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.797 X-Spam-Level: X-Spam-Status: No, score=-9.797 tagged_above=-999 required=5 tests=[AWL=0.801, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 irf2ZwJaCc52 for ; Sat, 18 Dec 2010 08:09:22 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 655633A6A27 for ; Sat, 18 Dec 2010 08:09:21 -0800 (PST) X-CheckPoint: {4D0CDD1E-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 oBIGB9V8016098; Sat, 18 Dec 2010 18:11:09 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 18 Dec 2010 18:11:09 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 18 Dec 2010 18:11:09 +0200 From: Yoav Nir To: Gaurav Poothia Date: Sat, 18 Dec 2010 18:11:07 +0200 Thread-Topic: [IPsec] Question about DH retry for IKEv2 Thread-Index: Acuezi4slqJAQiyhQT+5c2Q8XSBL/g== Message-ID: References: In-Reply-To: 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_D18398D2C0634D9ABDD1E4BCA760A6C3checkpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Brian Swander , Gabriel Montenegro Subject: Re: [IPsec] Question about DH retry for 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: Sat, 18 Dec 2010 16:09:23 -0000 --_000_D18398D2C0634D9ABDD1E4BCA760A6C3checkpointcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Gaurav. In IKEv2, we don't call them cookies any more, but IKE SPIs. Since you're i= nitiating, you start with just the initiator IKE SPI (not a pair), and the = message ID for the first message is zero, not 1. IKE SA INIT messages always have message ID zero. I would bet that many imp= lementations rely on this. So you should really use a new initiator IKE SPI= . Yoav On Dec 17, 2010, at 8:05 PM, Gaurav Poothia wrote: Hello, Re: Part of RFC 5996 Sec 1.2 that talks about DH retry in the case initiato= r guesses the wrong DH group in SA INIT It=92s not clear to me whether the expectation is for the second SA INIT a= ttempt (this time with the DH group hinted at by peer) can start afresh wit= h a new IKE cookie pair (message ID 1) OR If it must retain the existing cookie pair (message ID 2) AFAICT either way is acceptable since both achieve the same end. The former= seems slightly easier. Pls correct me though if one approach is strictly the right way. If so then= why. Thanks --_000_D18398D2C0634D9ABDD1E4BCA760A6C3checkpointcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Gaurav.

In IKEv2, we don't call them cookies any mor= e, but IKE SPIs. Since you're initiating, you start with just the initiator= IKE SPI (not a pair), and the message ID for the first message is zero, no= t 1.

IKE SA INIT messages always have message ID z= ero. I would bet that many implementations rely on this. So you should real= ly use a new initiator IKE SPI.

Yoav
On Dec 17, 2010, at 8:05 PM, Gaurav Poothia wrote:

<= div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; m= argin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; ">Hello= ,
 
Re: Part of RFC 5996 Sec 1.2 that talks= about DH retry in the case initiator guesses the wrong DH group in SA INIT=
 
It=92s not clear to me whether the expe= ctation is for the second  SA INIT attempt (this time with the DH grou= p hinted at by peer) can start afresh with a new IKE cookie pair (message I= D 1)
OR
If it must retain the existing cookie pair = (message ID 2)
 
AFAICT either way is acceptab= le since both achieve the same end. The former seems slightly easier.<= /o:p>
Pls correct me though if one approach is strictly the right way. If = so then why.
 
Thanks
<ATT00002..txt>

<= /body>= --_000_D18398D2C0634D9ABDD1E4BCA760A6C3checkpointcom_-- From gpoothia@microsoft.com Sat Dec 18 09:47:29 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 D72843A6B56 for ; Sat, 18 Dec 2010 09:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 xQCY84Xny+kB for ; Sat, 18 Dec 2010 09:47:25 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id A130A3A6B59 for ; Sat, 18 Dec 2010 09:47:25 -0800 (PST) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 18 Dec 2010 09:49:15 -0800 Received: from TK5EX14MBXC116.redmond.corp.microsoft.com ([169.254.7.144]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0255.003; Sat, 18 Dec 2010 09:49:14 -0800 From: Gaurav Poothia To: Yoav Nir Thread-Topic: [IPsec] Question about DH retry for IKEv2 Thread-Index: AcueE2fY8xVTTn24QwWyMbvbEVsW1gA/dOOAAA1NGWA= Date: Sat, 18 Dec 2010 17:49:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_B69601AD18064F4BBA2D61CA82AEAFA928187638TK5EX14MBXC116r_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Brian Swander , Gabriel Montenegro Subject: Re: [IPsec] Question about DH retry for 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: Sat, 18 Dec 2010 17:47:29 -0000 --_000_B69601AD18064F4BBA2D61CA82AEAFA928187638TK5EX14MBXC116r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Yoav for your response. Yes I was off by one wrt the message IDs. New IKE SPI sounds reasonable to me too. Gaurav From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Saturday, December 18, 2010 9:41 PM To: Gaurav Poothia Cc: ipsec@ietf.org; Brian Swander; Gabriel Montenegro Subject: Re: [IPsec] Question about DH retry for IKEv2 Hi Gaurav. In IKEv2, we don't call them cookies any more, but IKE SPIs. Since you're i= nitiating, you start with just the initiator IKE SPI (not a pair), and the = message ID for the first message is zero, not 1. IKE SA INIT messages always have message ID zero. I would bet that many imp= lementations rely on this. So you should really use a new initiator IKE SPI= . Yoav On Dec 17, 2010, at 8:05 PM, Gaurav Poothia wrote: Hello, Re: Part of RFC 5996 Sec 1.2 that talks about DH retry in the case initiato= r guesses the wrong DH group in SA INIT It's not clear to me whether the expectation is for the second SA INIT att= empt (this time with the DH group hinted at by peer) can start afresh with = a new IKE cookie pair (message ID 1) OR If it must retain the existing cookie pair (message ID 2) AFAICT either way is acceptable since both achieve the same end. The former= seems slightly easier. Pls correct me though if one approach is strictly the right way. If so then= why. Thanks --_000_B69601AD18064F4BBA2D61CA82AEAFA928187638TK5EX14MBXC116r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Yoav for your resp= onse.

Yes I was off by one wrt = the message IDs.

 <= /p>

New IKE SPI sounds reason= able to me too.

 <= /p>

Gaurav<= /p>

 <= /p>

 <= /p>

From: Yoav Nir= [mailto:ynir@checkpoint.com]
Sent: Saturday, December 18, 2010 9:41 PM
To: Gaurav Poothia
Cc: ipsec@ietf.org; Brian Swander; Gabriel Montenegro
Subject: Re: [IPsec] Question about DH retry for IKEv2

 

Hi Gaurav.

 

In IKEv2, we don't call them cookies any more, but I= KE SPIs. Since you're initiating, you start with just the initiator IKE SPI= (not a pair), and the message ID for the first message is zero, not 1.

 

IKE SA INIT messages always have message ID zero. I = would bet that many implementations rely on this. So you should really use = a new initiator IKE SPI.

 

Yoav

 

On Dec 17, 2010, at 8:05 PM, Gaurav Poothia wrote:



Hello,

 

Re: Part of RFC 5996 Sec 1.2 that ta= lks about DH retry in the case initiator guesses the wrong DH group in SA I= NIT

 

It’s not clear to me whether the = expectation is for the second  SA INIT attempt (this time with the DH = group hinted at by peer) can start afresh with a new IKE cookie pair (message ID 1)

OR

If it must retain the existing cookie p= air (message ID 2)

 

AFAICT either way is acceptable since b= oth achieve the same end. The former seems slightly easier.

Pls correct me though if one approach i= s strictly the right way. If so then why.

 

Thanks

<ATT00002..txt><= /p>

 

--_000_B69601AD18064F4BBA2D61CA82AEAFA928187638TK5EX14MBXC116r_-- From wenrongbupt@gmail.com Sat Dec 18 05:05:48 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 04AC93A6A00 for ; Sat, 18 Dec 2010 05:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_65=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 gjyhwU17-Zu2 for ; Sat, 18 Dec 2010 05:05:45 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 1DBC03A69FF for ; Sat, 18 Dec 2010 05:05:45 -0800 (PST) Received: by iyi42 with SMTP id 42so1139663iyi.31 for ; Sat, 18 Dec 2010 05:07:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type; bh=q2NNu/v7I1cTzQYnV8rPMWY1TuxOWeCitvE7WavB6aQ=; b=qkkEVjrc8DuXvgZQfXB9iXqJp96fkYw8mDvt0iHkqlEGCVai8EXXQiYcNzpwS/dArs zdQngF9yT9liNEcOKXJJuYyvFStQZvp7OpLQ0bIJcfk6h7bvIktoy6PjyhsWNiPWkh3W gP5wjzomxty9jOGjN90bX6lIxZL2FqURHp+Tk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type; b=ILtdObr3+G3b3VtTEjcIg+1MKnfMbo3PBYkw9lly2JLPpUzXQj87+VJ6gL9gwPsg4n N9Fb849FFJsCVcvDDm9hp92z0mJ0hlZh/16EK0blJdKqqgT6x5LgqZnK87rOjAYwhuzq EJwd+RBAEJfUnayKkntscHOdnfYpTS9RN9PVw= Received: by 10.231.182.85 with SMTP id cb21mr1933320ibb.44.1292677654033; Sat, 18 Dec 2010 05:07:34 -0800 (PST) Received: from bupt-wenrong ([118.229.168.29]) by mx.google.com with ESMTPS id z4sm1330333ibg.1.2010.12.18.05.07.30 (version=SSLv3 cipher=RC4-MD5); Sat, 18 Dec 2010 05:07:33 -0800 (PST) Date: Sat, 18 Dec 2010 21:07:27 +0800 From: "wenrongbupt" To: "ipsec" Message-ID: <201012182107238908581@gmail.com> X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon365635108215_=====" X-Mailman-Approved-At: Sat, 18 Dec 2010 12:02:23 -0800 Subject: [IPsec] SA in the kernel's SADB is how to store? 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, 18 Dec 2010 13:20:24 -0000 This is a multi-part message in MIME format. --=====003_Dragon365635108215_===== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I am a new guy.I want to know the SA in the kernel's SADB is how to store? And,I also want to know the ike daemon(pluto or racoon)is how to write the SA to the SADB? Recently,I am reading the sourcecode of pluto,but I don't found the interface,which to finish write the SA to the SADB. So,I need your help.If you can help me,please send the mail to wenrongbupt@gmail.com. For your letter, I was very grateful .Thank your very much. Best Regards Vincent 2010-12-18 wenrongbupt --=====003_Dragon365635108215_===== Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
Hello，
I am a new guy.I want to know the SA in the kernel's SADB is how to store?
 
And,I also want to know the ike daemon(pluto or racoon)is how to write the SA to the SADB?
 
Recently,I am reading the sourcecode of pluto,but I don't found the interface,which to finish write the SA to the SADB.
 
So,I need your help.If you can help me,please send the mail to wenrongbupt@gmail.com.
 
For your letter, I was very grateful .Thank your very much.
 
 
Best Regards
Vincent
2010-12-18
wenrongbupt
--=====003_Dragon365635108215_=====-- From wenrongbupt@gmail.com Mon Dec 20 06:14: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 36F663A6995 for ; Mon, 20 Dec 2010 06:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-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 JBIx3cOFzzdR for ; Mon, 20 Dec 2010 06:14:18 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 1DBE13A68CB for ; Mon, 20 Dec 2010 06:14:18 -0800 (PST) Received: by vws7 with SMTP id 7so1225739vws.31 for ; Mon, 20 Dec 2010 06:16:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type; bh=f4kFTEdfdRYOlhMH8xu4c/r+PLL8Gl7tYMMF/qIfYXc=; b=A2rzlO94h9nHyQBEiGZ2UqisIO0uwkx/8kTa+Lm6hru/LVKAYQmPS1rA9bGgCktjh/ RxB5etVgdQyDqZS78XvGNxjuCK7GO7Yo47Dk3GadVeRpI6DJOTxJ74li+sv3PTmn/1pF 9KCWzEnDX3VkKADPn0TeU/oRqToqM0SJ5BJp8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type; b=bpzhooxrCqlBGXE03mVe6D9ZUf9oaQHnGK9sszldgtsCZZKU4uKUq9pgL819Tq58WQ 28O7UKvYT0hasp/mZ4YUU5m54c3XsbvActxcS+iso58jy1/NO1JLxu9qmKRCxQShnlXB wksSfuWTRrja1Q5v16//ekohg6eM0fp+HcdzA= Received: by 10.220.191.70 with SMTP id dl6mr1051112vcb.268.1292854571573; Mon, 20 Dec 2010 06:16:11 -0800 (PST) Received: from bupt-wenrong ([123.119.241.75]) by mx.google.com with ESMTPS id u6sm1398799vby.17.2010.12.20.06.16.07 (version=SSLv3 cipher=RC4-MD5); Mon, 20 Dec 2010 06:16:11 -0800 (PST) Date: Mon, 20 Dec 2010 22:16:04 +0800 From: "wenrongbupt" To: "ipsec" Message-ID: <201012202215599371487@gmail.com> X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon108532146360_=====" Subject: [IPsec] installation errors 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, 20 Dec 2010 14:14:19 -0000 This is a multi-part message in MIME format. --=====003_Dragon108532146360_===== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, When I install ipsec-tools(the version is 0.7.2),there are some errors as following: sockmisc.c: In function 'recvfromto': sockmisc.c:388: error: dereferencing pointer 'ss.46' does break strict-aliasing rules sockmisc.c:388: note: initialized from here sockmisc.c:406: error: dereferencing pointer 'ss.47' does break strict-aliasing rules I have seached these errors in Internet,but didn't found. So,I need your help.If you can help me,please send the mail to wenrongbupt@gmail.com. For your letter, I was very grateful .Thank your very much. Best Regards Vincent --=====003_Dragon108532146360_===== Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
Hello,
 
When I install ipsec-tools(the version is 0.7.2),there are some errors as following:
 
sockmisc.c: In function 'recvfromto':
sockmisc.c:388: error: dereferencing pointer 'ss.46' does break strict-aliasing rules
sockmisc.c:388: note: initialized from here
sockmisc.c:406: error: dereferencing pointer 'ss.47' does break strict-aliasing rules
 
I have seached these errors in Internet,but didn't found.
 
So,I need your help.If you can help me,please send the mail to wenrongbupt@gmail.com.
 
For your letter, I was very grateful .Thank your very much.
 
 
Best Regards
Vincent
 
--=====003_Dragon108532146360_=====-- From paul.hoffman@vpnc.org Mon Dec 20 08:35: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 766A03A6A59 for ; Mon, 20 Dec 2010 08:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.379 X-Spam-Level: X-Spam-Status: No, score=-100.379 tagged_above=-999 required=5 tests=[AWL=-0.747, BAYES_40=-0.185, 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 Gz53-4lzwUzz for ; Mon, 20 Dec 2010 08:35:35 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id C05AF3A699A for ; Mon, 20 Dec 2010 08:35:35 -0800 (PST) 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 oBKGbQSF050602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Dec 2010 09:37:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <201012202215599371487@gmail.com> References: <201012202215599371487@gmail.com> Date: Mon, 20 Dec 2010 08:37:25 -0800 To: "wenrongbupt" , "ipsec" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] installation errors 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, 20 Dec 2010 16:35:36 -0000 This is the wrong mailing list to ask about specific pieces of software that implement IPsec. Instead, you need to go to the mailing list for that specific software. This mailing list is for discussing the development of the IPsec protocol. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Mon Dec 20 09:50: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 29CBE3A6844 for ; Mon, 20 Dec 2010 09:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.381 X-Spam-Level: X-Spam-Status: No, score=-100.381 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_40=-0.185, 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 EU3TfMIgmAMF for ; Mon, 20 Dec 2010 09:50:13 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id D88F73A67D4 for ; Mon, 20 Dec 2010 09:50:12 -0800 (PST) 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 oBKHq5vu054549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Dec 2010 10:52:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 20 Dec 2010 09:52:04 -0800 To: "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] QCD applicability (issues #198 and #201) 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, 20 Dec 2010 17:50:14 -0000 I am going to close these issues accepting Yoav's proposal from 2010-12-13. Not only would it be nice, but it would be *really useful to the IPsec community*, if there were more people in the WG who were reading our two remaining documents and commenting on the open issues... --Paul Hoffman, Director --VPN Consortium From ynir@checkpoint.com Sun Dec 26 01:36:02 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 AC76928C0DE for ; Sun, 26 Dec 2010 01:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.819 X-Spam-Level: X-Spam-Status: No, score=-9.819 tagged_above=-999 required=5 tests=[AWL=0.780, 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 T63TNTQN49JD for ; Sun, 26 Dec 2010 01:36:01 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 12BFA28C0D8 for ; Sun, 26 Dec 2010 01:36:00 -0800 (PST) X-CheckPoint: {4D170CFC-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 oBQ9c4rm021674 for ; Sun, 26 Dec 2010 11:38:04 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 26 Dec 2010 11:38:03 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sun, 26 Dec 2010 11:38:03 +0200 From: Yoav Nir To: "ipsec@ietf.org" Date: Sun, 26 Dec 2010 11:38:03 +0200 Thread-Topic: Failure Detection - Issue #200 Thread-Index: Acuk4JevOQYlfUuCTgeNuiYk3zL0iQ== Message-ID: <4482BE0E-93AF-44B0-A4DF-302994312D31@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Failure Detection - Issue #200 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, 26 Dec 2010 09:36:02 -0000 Hi all.=20 Issue #200 is about some text in section 8 ("Interaction with Session Resum= ption"). The text says that a rebooted peer (and thus a defunct SA) may go = undetected for the lifetime of the SA. However, RFC 5996 says that at some = point, a peer that did not receive incoming traffic on a particular IKE SA = or its children, has to initiate a liveness check. Here's how I propose to resolve this. Seeing as it's the holiday season, I= won't close the issue until January 10th, but please get your comments in = by then. Existing text: What Session Resumption does not help is the problem of detecting that the peer gateway has failed. A failed gateway may go undetected for as long as the lifetime of a child SA, because IPsec does not have packet acknowledgement, and applications cannot signal the IPsec layer that the tunnel "does not work". 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. My proposed text: What Session Resumption does not help is the problem of detecting that the peer gateway has failed. A failed gateway may go undetected for an arbitrarily long time, because IPsec does not have packet acknowledgement, and applications cannot signal the IPsec layer that the tunnel "does not work". Section 2.4 of RFC 5996 does not specify how long an implementation needs to wait before beginning a liveness check, and only says "not recently" (see full quote in Section 2). In practice some mobile devices wait a very long time before beginning liveness check, in order to extend battery life by allowing parts of the device to remain in low-power modes. QCD tokens provide a way to detect the failure of the peer in the case where liveness check has not yet ended (or begun).