From raghup@cisco.com Mon Mar 2 04:55:07 2009 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 1841328C101 for ; Mon, 2 Mar 2009 04:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 C+HMAIC2XfwX for ; Mon, 2 Mar 2009 04:55:03 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id CE24528C0FB for ; Mon, 2 Mar 2009 04:55:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,289,1233532800"; d="scan'208,217";a="65462951" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 02 Mar 2009 12:55:30 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n22CtTZZ009531 for ; Mon, 2 Mar 2009 04:55:29 -0800 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n22CtSe9022503 for ; Mon, 2 Mar 2009 12:55:29 GMT Received: from XMB-BLR-419.apac.cisco.com ([64.104.140.154]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 18:25:27 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99B36.292730CF" Date: Mon, 2 Mar 2009 18:25:27 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on Authentication failure Thread-Index: AcmbNijEj+qB6GAQQu6jybqpRaPB8A== From: "Raghunandan P (raghup)" To: X-OriginalArrivalTime: 02 Mar 2009 12:55:27.0475 (UTC) FILETIME=[28F98430:01C99B36] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5137; t=1235998529; x=1236862529; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raghup@cisco.com; z=From:=20=22Raghunandan=20P=20(raghup)=22=20 |Subject:=20Question=20on=20Authentication=20failure |Sender:=20; bh=DTDBAAxob6ToxLXXhqVhkL9yJ/yMB3uukOapog2XeBg=; b=ecZEMKAH2/ECFOIN6wigVxZVds90NewHMyz6jt7Q1PFf6f6XfgKffExgRF 3apIth+RrZG+j2zXrWC5KWAIqPMAMAtHFMXdgmfrMr2qCMO6mLkbjboB7FxJ 9KMWKQje+IBcHGmu1nD6kH9OYECgCBwY3Wtx0F2k4eQR2fHRNMCJA=; Authentication-Results: sj-dkim-1; header.From=raghup@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [IPsec] Question on Authentication failure 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, 02 Mar 2009 12:55:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99B36.292730CF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I needed a clarification related to handling of Authentication failure on the initiator and responder sides. =20 During the IKEv2 negotiation, suppose an authentication failure occurs on the responder side, a Notify payload with AUTHENTICATION_FAILURE is sent in the AUTH_EXCH response back to the initiator (Message 4). Is this correct? Will there be any ACK sent from the initiator for this notification? =20 Suppose the authentication failure happens on the initiator (and not the responder), how is this handled? Does initiator send an explicit Notify to the responder, which needs to respond back with an ACK? =20 The draft mentions the following: "AUTHENTICATION_FAILED 24 Sent in the response to an IKE_AUTH message when for some reason the authentication failed. There is no associated data." =20 More clarity will help. =20 Thanks Raghu =20 ------_=_NextPart_001_01C99B36.292730CF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I needed a clarification = related to=20 handling of Authentication failure on the initiator and responder = sides.

 

During the IKEv2 = negotiation,=20 suppose an authentication failure occurs on the responder side, a = Notify=20 payload with AUTHENTICATION_FAILURE is sent in the AUTH_EXCH response = back to=20 the initiator (Message 4). Is this correct? Will there be any ACK=20 sent from the initiator for = this=20 notification?

 

Suppose the authentication = failure=20 happens on the initiator (and not the=20 responder), how is this handled? Does initiator send an explicit Notify to the responder, which needs = to respond=20 back with an = ACK?

 

The draft mentions the = following:

“AUTHENTICATION_FAILED      &n= bsp;           &nb= sp;=20 24
       Sent in the response to an = IKE_AUTH=20 message when for some reason
       the = authentication failed. There is no associated = data.”

 

More clarity will = help.

 

Thanks

Raghu

 
------_=_NextPart_001_01C99B36.292730CF-- From kivinen@iki.fi Mon Mar 2 06:05:24 2009 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 D2F3328C1E6 for ; Mon, 2 Mar 2009 06:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 jkpQbUTt6KjI for ; Mon, 2 Mar 2009 06:05:24 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 4E47128C21B for ; Mon, 2 Mar 2009 06:05:22 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n22E5NRx006406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 16:05:23 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n22E5NVY003493; Mon, 2 Mar 2009 16:05:23 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18859.59299.124765.754423@fireball.kivinen.iki.fi> Date: Mon, 2 Mar 2009 16:05:23 +0200 From: Tero Kivinen To: "Raghunandan P (raghup)" In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 19 min X-Total-Time: 21 min Cc: ipsec@ietf.org Subject: [IPsec] Question on Authentication failure 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, 02 Mar 2009 14:05:24 -0000 Raghunandan P (raghup) writes: > During the IKEv2 negotiation, suppose an authentication failure occurs > on the responder side, a Notify payload with AUTHENTICATION_FAILURE is > sent in the AUTH_EXCH response back to the initiator (Message 4). Is > this correct? Yes. We do have open ticket for ikev2bis whether that notification should be sent unencrypted or not. As we have not finished authentication we cannot send it authenticated, but as we have finished Diffie-Hellman we can send it encrypted and integrity protected if we like. Sending it encrypted and integrity protected does provide proof that the error was sent by the party who participated in the Diffie-Hellman exchange in the IKE_SA_INIT, but it does not provide proof that the party is actually the intended party you tried to talk to (i.e. it could be man in the middle attacker). See the 2nd part of the ticket #9 for the ikev2bis document and the related ongoing discussion on the IPsec list. > Will there be any ACK sent from the initiator for this > notification? No. As that error will be sent as response to the request sent by the initiator, there cannot be any response to response packet (section 3.1: "An IKE endpoint MUST NOT generate a response to a message that is marked as being a response."). > Suppose the authentication failure happens on the initiator (and not the > responder), how is this handled? Does initiator send an explicit Notify > to the responder, which needs to respond back with an ACK? If the authentication failure happens on the initiator side, initiator has two options. 1) It can simply silently delete the half-created IKE SA, and fail the connection attempt (for his point of view the IKE SA was never created, thus it is allowed to do that). Responder who thinks the IKE SA exchange was successful will keep the IKE SA up, and as there is no traffic at all over it, it will most likely trigger some dead peer detection query after some timeout, and as initiator does not have the IKE SA up, it will not reply to those, and after the timeout the responder will also delete the IKE SA because it failed dead peer detection. 2) It can finish creation of the IKE SA, but mark it as failed, then after that it can start new INFORMATIONAL exchange in the IKE SA and send request containing delete payload to the responder. When responder receives that it will delete the IKE SA and send empty response back (responder still needs to keep IKE SA alive for some timeout, in case the response was lost and initiator retransmits its request). When that response is received by initiator it will delete the IKE SA. The second option has problems as it creates "unauthenticated" IKE SA which could be used to attack the initiator unless the initiator is protected by such by making sure that no exchanges can be done over that IKE SA. This requires implementations to understand that this IKE SA has special status of unauthenticated. The first option on the other hand does not delete the IKE SA from the responder, thus responder will still think the IKE SA is up and alive, and will keep it there wasting resources until the dead peer detection fails. I think the most common case is to use the first option, as it does not really require any extra code, and initiator end will still log that connection failed, thus for example in remote access cases the interactive user who initiated the connection will see that and can change configuration etc to fix the situation. And as responder already did manage to authenticate the initiator, this cannot be used as unathenticated denial of service attack. -- kivinen@iki.fi From Pasi.Eronen@nokia.com Mon Mar 2 12:03:57 2009 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 413333A659C for ; Mon, 2 Mar 2009 12:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.03 X-Spam-Level: X-Spam-Status: No, score=-6.03 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, J_BACKHAIR_23=1, 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 9Eug9zBNFLLA for ; Mon, 2 Mar 2009 12:03:56 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id A3B4E3A6820 for ; Mon, 2 Mar 2009 12:03:55 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n22K4661026059 for ; Mon, 2 Mar 2009 22:04:18 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Mar 2009 22:04:18 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Mar 2009 22:04:13 +0200 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 2 Mar 2009 21:04:12 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Mon, 2 Mar 2009 21:04:12 +0100 From: To: Date: Mon, 2 Mar 2009 21:04:09 +0100 Thread-Topic: WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 Thread-Index: AcmQG11xz3Y00zEpSza195DYpuB4qgLVe3mQ Message-ID: <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.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 X-OriginalArrivalTime: 02 Mar 2009 20:04:13.0373 (UTC) FILETIME=[0ECE06D0:01C99B72] X-Nokia-AV: Clean Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 02 Mar 2009 20:03:57 -0000 I have one somewhat substantial concern with the document: it needs to be much clearer about what information is updated by the received REDIRECT messages, and what is not. While selecting the right peer when a new ESP/AH SA needs to be created is not specified in RFC 4301 (see RFC 4555 Appendix A.2 for some discussion), PAD definitely is in scope, and redirect could interact with PAD in multiple ways. For example, suppose the client decides that the right peer for the ESP/AH SA is gw1.example.com. If after doing a DNS lookup and contacting gw1.example.com it receives IDr/CERT payloads for gw2.foobar.example, the client would report error and abort (at least unless "the right peer for the SA" is actually a set of possible peers, and gw2 happens to be in that set). Now, suppose contacting gw1.example.com results in REDIRECT to gw2.foobar.example (GW Identity Type=3DFQDN). When the client contacts gw2, and receives IDr/CERT for gw2.foobar.example, does it accept it? One possible answer would be that REDIRECT is interpreted just as data received from DNS, so all the gateways (redirecting among each other) would send same IDr value. Another possible answer would be that if gw2.foobar.example is already in client's local "set of right peers for this SA", then it would be accepted (and the client would have accepted IDr/CERT with gw2.foobar.example also in the beginning, before it got the redirect), otherwise not. (And the client will also accept IDr/CERT gw1.example.com even after the redirect, when contacting gw2 ---that would be the sensible behavior if the redirect was with GW Identity Type=3DIPv4/6.) (Other answers than these two might be possible, too -- I have not explored this in detail.) Now, it's quite obvious the intent was to do redirect securely, but we need to spell out what the correct behavior is: do all the gateways have a single identity (IDr), or do they have distinct PAD entries? (In the latter case, IKE_SA creation (with or without redirects) succeeds only if the IDr has an entry in the PAD, and the peer is successfully authenticated as required by the PAD. If the client accepts IDr/CERT gw2.foobar.example, it would have also accepted it in the first place (when trying to contact the IP address found by doing DNS lookup for gw1.example.com, before it got any redirects). However, in general there's no guarantee that the CHILD_SA authorization data for the PAD entries "gw1.example.com" and "gw2.foobar.example" is exactly the same, so although setting up the IKE_SA succeeds, creating CHILD_SA with the intended selectors might not -- so by sending a redirect, the gateway really assumes that the client has identical CHILD_SA authorization data for the target.) The situation gets tricker when we consider Mobile IPv6, though, because we're also updating some data outside IPsec. What exactly is being updated by the received REDIRECT, and is this secure? Also, the SPD entries in RFC 4877 contain the HA address -- are we updating SPD entries based on unauthenticated REDIRECT? It seems some of this problem is already present in current MIP6 bootstrapping documents (if we e.g. discover Home Agent IPv6 address by DNS query, somehow the SPD entries must get there, based on usually unauthenticated DNS response), and it's possible we could refer to that work. But "treat REDIRECT just as it would have come from DNS" is not without security issues, since MN might not use DNS to get the HA address (we could be overwriting manually configured data known to be secure), the DNS reply could have been protected by DNSSEC, or=20 the attacker might be on MN<->GW1 path (and can spoof redirects) but=20 not on MN/DNS server paths (so can't spoof the DNS reply). Minor clarifications and nits: - Section 4 says "If an anycast address is returned in response to DNS resolution of an FQDN, the IKEv2 transaction between the VPN client and the VPN gateway is slightly modified." It seems the transaction is actually *not* modified at all -- it's exactly identical to the unicast case (and VPN client can't tell which case occurred)? - Section 5: I don't think treating REDIRECT+"sufficient time period" as implicit delete is a good idea. RFC 4306 requires sending delete payloads whenever possible, and if the VPN GW wants to close the IKE_SA, it could include the Delete payload in the same message as the REDIRECT notification... - Section 6.1/6.2/6.3: should say that Protocol ID is set to zero. - Section 6.2 says this message is included in IKE_SA_INIT response;=20 also INFORMATIONAL request, right? - Section 7: I'm a bit skeptical if this actually works. The rest of the document certainly does not describe how it would work, and in many places, assumes the client-gateway case (e.g. Section 6.1 says REDIRECT_SUPPORTED is only sent in initial IKE_SA_INIT request, so the responder can't actually tell the initiator it supports this feature, etc.) Also, the "what is actually updated by REDIRECT and what is not" may get even more complex in peer-to-peer case. My personal preference would be to restrict the scope to client-gateway unless someone really has the energy needed to specify how the peer-to-peer case works in detail. Best regards, Pasi= From kent@bbn.com Mon Mar 2 16:39:23 2009 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 ED7083A6849 for ; Mon, 2 Mar 2009 16:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.317, 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 afnuiQkIM3JF for ; Mon, 2 Mar 2009 16:39:23 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 4A0303A66B4 for ; Mon, 2 Mar 2009 16:39:23 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.71.0.151]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LeIfl-0000kf-EC; Mon, 02 Mar 2009 19:39:49 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> Date: Mon, 2 Mar 2009 19:37:09 -0500 To: From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ipsec@ietf.org Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 03 Mar 2009 00:39:24 -0000 Pasi, I agree with your observations/concerns. Any host/SG to which one is redirected needs to be subject to the same controls as an initial SA target. I see this as a PAD (and SPD) issue. I would suggest that maybe the only safe approach is to reevaluate the redirected target against the PAD entry for the initial target. Steve From yaronf@checkpoint.com Tue Mar 3 01:58:10 2009 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 549A828C22C for ; Tue, 3 Mar 2009 01:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, 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 nx6waAPy8aDa for ; Tue, 3 Mar 2009 01:58:09 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id A011328C21F for ; Tue, 3 Mar 2009 01:57:15 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n239vF16008234 for ; Tue, 3 Mar 2009 11:57:15 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 3 Mar 2009 11:57:15 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 3 Mar 2009 11:57:13 +0200 Thread-Topic: re: WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 Thread-Index: Acmb5m1Kl97b7r+LSJKn+nRPvP5FKA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EB7D@il-ex01.ad.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: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 03 Mar 2009 09:58:10 -0000 Hi, The last call was completed. There were two major issues and some additiona= l comments, as well as one outstanding open issue. 1. Redirect during IKE_AUTH: this was reopened, several people expressed un= ease with the solution as stated in -04. 2. Interaction of Redirect with IPsec authorization (the PAD), this is defi= nitely important, and requires a clarification. Re: #1, I suggest that the authors review this issue in view of the opinion= s expressed on the list, and post their decision to the list. Re: #2, the authors are requested to post new text on the list for discussi= on. As soon as these issues are resolved, I would like to start a new LC, based= on version -05 of the draft. Thanks, Yaron From kivinen@iki.fi Tue Mar 3 07:29:52 2009 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 103783A6938 for ; Tue, 3 Mar 2009 07:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 IIkJs1NdzFPQ for ; Tue, 3 Mar 2009 07:29:51 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A0F033A68C3 for ; Tue, 3 Mar 2009 07:29:50 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n23FUEEl014467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 17:30:14 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n23FUDt6012788; Tue, 3 Mar 2009 17:30: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: <18861.19717.483315.281468@fireball.kivinen.iki.fi> Date: Tue, 3 Mar 2009 17:30:13 +0200 From: Tero Kivinen To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 26 min X-Total-Time: 37 min Cc: ipsec@ietf.org Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 03 Mar 2009 15:29:52 -0000 Pasi.Eronen@nokia.com writes: > I have one somewhat substantial concern with the document: it needs to > be much clearer about what information is updated by the received > REDIRECT messages, and what is not. Never really thought that issue. I myself assumed that both GWs are identical, i.e. they return same ID, and use same authentication data (i.e. if PSK, both use same PSK, if certs, both authenticate against same trust anchor and use same identity in cert, but not necessarely same private key). > One possible answer would be that REDIRECT is interpreted just as data > received from DNS, so all the gateways (redirecting among each other) > would send same IDr value. I think this is the easiest way to make sure redirect is secure. > - Section 5: I don't think treating REDIRECT+"sufficient time period" > as implicit delete is a good idea. RFC 4306 requires sending delete > payloads whenever possible, and if the VPN GW wants to close the > IKE_SA, it could include the Delete payload in the same message as the > REDIRECT notification... I think it said that it can delete it without client sending any packets, but that delete is not implicit, it is explicit, and gateway will then send delete payload to delete the IKE SA. The sufficient time is used when the client has been talking to the gateway for longer already, and has multiple IPsec SAs up and in use. Then when gateway decides to redirect client somewhere else it sends N(REDIRECT) and client acks that. After that client starts recreating existing IKE SA and Child SAs with the new gateway, and after finishing that the client will delete the IKE SA with delete payload. If server runs out of resources before that it can send delete payload even before client finishes its redirection process but as that causes disruption of the flow of packets (if client didn't have time to set up new Child SAs), server should allow some time for that. I agree that the text could be written in more clear way, i.e. explictly say that the "delete the securition association" does mean the normal IKEv2 way, i.e. sending delete payload. > - Section 7: I'm a bit skeptical if this actually works. The rest of > the document certainly does not describe how it would work, and in > many places, assumes the client-gateway case (e.g. Section 6.1 says > REDIRECT_SUPPORTED is only sent in initial IKE_SA_INIT request, so the > responder can't actually tell the initiator it supports this feature, > etc.) Also, the "what is actually updated by REDIRECT and what is not" > may get even more complex in peer-to-peer case. My personal > preference would be to restrict the scope to client-gateway unless > someone really has the energy needed to specify how the peer-to-peer > case works in detail. Also the current text says "the responder MUST NOT respond to re-direct message from the initiator, if it has already decided to re-direct the initiator." and that is impossible with IKEv2. If node receives some request, it must reply with response, it cannot leave that response out, as if he does that then the IKE SA will be teared down when the other end times out the exchange. I think the original idea was that even when we talk about VPN client and gateway, this could be used as building block for other things too, and even this document uses terms like "VPN client" and "VPN gateway", this could also be used even when the IKE peers are not VPN client/gateway. This includes cases where for example SIP/MobileIP client connects to SIP/MobileIP server using IPsec. I do not think this can be used as generic gateway to gateway redirection mechinism (MOBIKE can be used for that too). I.e. I would simply change the section 7. to contain: ---------------------------------------------------------------------- 7. Use of the Redirect Mechanism between IKEv2 Peers The Re-direct mechanism described in this document is mainly intended for use in client-gateway scenarios. However, the mechanism can also be used between any two IKEv2 peers, but this protocol is asymmetric, meaning that only the responder can redirect initiator to some other server. ---------------------------------------------------------------------- And leave everything else out, including changing the protocol so it can be used in both directions. -- kivinen@iki.fi From paul.hoffman@vpnc.org Tue Mar 3 07:56:42 2009 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 326593A680F for ; Tue, 3 Mar 2009 07:56:42 -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 Yfezo1tWfTOP for ; Tue, 3 Mar 2009 07:56:41 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 055A23A6452 for ; Tue, 3 Mar 2009 07:56:40 -0800 (PST) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n23Fv2Yr054359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 08:57:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18861.19717.483315.281468@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <18861.19717.483315.281468@fireball.kivinen.iki.fi> Date: Tue, 3 Mar 2009 07:57:00 -0800 To: Tero Kivinen , From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ipsec@ietf.org Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 03 Mar 2009 15:56:42 -0000 At 5:30 PM +0200 3/3/09, Tero Kivinen wrote: >Pasi.Eronen@nokia.com writes: >> I have one somewhat substantial concern with the document: it needs to >> be much clearer about what information is updated by the received >> REDIRECT messages, and what is not. > >Never really thought that issue. I myself assumed that both GWs are >identical, i.e. they return same ID, and use same authentication data >(i.e. if PSK, both use same PSK, if certs, both authenticate against >same trust anchor and use same identity in cert, but not necessarely >same private key). I think both views are reasonable, but the document must be much clearer about which is being discussed. If it is the former, the doc should also explicitly say that the latter is an acceptable setup. > > One possible answer would be that REDIRECT is interpreted just as data >> received from DNS, so all the gateways (redirecting among each other) >> would send same IDr value. > >I think this is the easiest way to make sure redirect is secure. I initially didn't agree with this idea, but I can see how it would make the security properties much easier to define. However, I don't think that was the intention of the current document. --Paul Hoffman, Director --VPN Consortium From yaronf@checkpoint.com Tue Mar 3 10:17:38 2009 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 692DF28C28A for ; Tue, 3 Mar 2009 10:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.144 X-Spam-Level: X-Spam-Status: No, score=-3.144 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 D3MXzbXYVU+9 for ; Tue, 3 Mar 2009 10:17:37 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 32CFE28C1DB for ; Tue, 3 Mar 2009 10:17:36 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n23II216029833 for ; Tue, 3 Mar 2009 20:18:02 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 3 Mar 2009 20:18:02 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 3 Mar 2009 20:18:01 +0200 Thread-Topic: Issue #42: Improve example of multiple proposals Thread-Index: AcmcGzoj/BsaiVskT5em6sf4IzM7kg== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6B@il-ex01.ad.checkpoint.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_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Bilex01adcheck_" MIME-Version: 1.0 Subject: [IPsec] Issue #42: Improve example of multiple proposals 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, 03 Mar 2009 18:17:38 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Bilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 3.3. Security Association Payload ... The Proposal structure contains within it a Proposal # and an IPsec protoco= l ID. Each structure MUST have a proposal number one (1) greater than the p= revious structure. The first Proposal in the initiator's SA payload MUST ha= ve a Proposal # of one (1). A proposal of AH or ESP would have two proposal= structures, one for AH with Proposal #1 and one for ESP with Proposal #2. Tero: I think the last sentence should be removed, as it is bit confusing and som= e people might read it 'AH and ESP' and interpret it as bundles. I do not r= eally consider AH or ESP style proposal that common to require example here= . Perhaps ESP with combined mode ciphers and ESP with normal ciphers + inte= grity algorithms would make better example. Paul: Not done. The current example is clearer than your proposed change be= cause few people understand combined modes, even if the current example is = far-fetched. A different, clearer example would be a good replacement for t= he current text. Yaron: a new proposal example would be appreciated! --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Bilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3.3. Security Association Payload

...

The Proposal structure contains within it a Proposal # and an IPsec protocol ID= . Each structure MUST have a proposal number one (1) greater than the previou= s structure. The first Proposal in the initiator's SA payload MUST have a Proposal # of one (1). A proposal of AH or ESP would have two proposal structures, one for AH with Proposal #1 and one for ESP with Pro= posal #2.

Tero:

I think the last sentence should be removed, as it is bit confusing and some people might read it 'AH and ESP' and interpret it as bundles. I do not really consider AH or ESP style proposal that common to require example here. Perh= aps ESP with combined mode ciphers and ESP with normal ciphers + integrity algorithms would make better example.

Paul: Not done. The current example is clearer than your proposed change because few people understand combined modes, even if the current example is far-fetche= d. A different, clearer example would be a good replacement for the current text= .

Yaron: a new proposal example would be appreciated!=

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Bilex01adcheck_-- From yaronf@checkpoint.com Tue Mar 3 10:17:57 2009 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 9EDFB3A6C08 for ; Tue, 3 Mar 2009 10:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ArO2egnOOm17 for ; Tue, 3 Mar 2009 10:17:54 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id AE46D28C1DB for ; Tue, 3 Mar 2009 10:17:39 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n23II516029852 for ; Tue, 3 Mar 2009 20:18:05 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 3 Mar 2009 20:18:05 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 3 Mar 2009 20:18:05 +0200 Thread-Topic: Issue #48: Change text re: document status vs. older RFCs Thread-Index: AcmcHQL+2hLc/jJxTJCSHd9u3nex2A== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6D@il-ex01.ad.checkpoint.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_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Dilex01adcheck_" MIME-Version: 1.0 Subject: [IPsec] Issue #48: Change text re: document status vs. older RFCs 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, 03 Mar 2009 18:17:57 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Dilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yaron: Sec. 1: 'intended to replace': the status WRT IKEv1 and IKEv2 is obv= iously very different. I suggest: [4306] has obsol= eted the IKEv1 document set. The current document replaces [IKEv2] and [Cla= rif] by a single unified description of the IKEv2 protocol. Paul: I think the current [wording] is actually more correct than the propo= sed rewording. Yaron: the text has been changed somewhat in the meantime. The current text= has: ... This memo describes such a protocol -- the Internet Key Exchange (IKE).= Version 1 of IKE was defined in RFCs 2407 [DOI], 2408 [ISAKMP], and 2409 = [IKEV1]. IKEv2 replaced all of those RFCs. IKEv2 was defined in [IKEV2] (R= FC 4306) and was clarified in [Clarif] (RFC 4718). This document replaces = and updates RFC 4306 and RFC 4718. I suggest to append this sentence to the above paragraph: IKEv2 was a major, non-backward compatible change to the IKE protocol; in c= ontrast, the current document is primarily a clarification of IKEv2, making= a minimum number of necessary changes to the protocol. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Dilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yaron: Sec. 1: 'intended to replace': the status WRT IKEv1 and IKEv2 is obviously very different. I suggest:

[4306] has obsoleted the = IKEv1 document set. The current document replaces [IKEv2] and [Clarif] by a singl= e unified description of the IKEv2 protocol.

Paul: I think the current [wording] is actually more correct than the proposed rewo= rding.

Yaron: the text has been changed somewhat in the meantim= e. The current text has:

 

… This memo describes su= ch a protocol -- the Internet Key Exchange (IKE).  Version 1 of IKE was def= ined in RFCs 2407 [DOI], 2408 [ISAKMP], and 2409 [IKEV1].  IKEv2 replaced all = of those RFCs. IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif]= (RFC 4718).  This document replaces and updates RFC 4306 and RFC 4718.=

 

I suggest to append this sentence to the above paragraph= :

 

IKEv2 was a major, non-backwar= d compatible change to the IKE protocol; in contrast, the current document is primarily a clarification of IKEv2, making a minimum number of necessary changes to the protocol.

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Dilex01adcheck_-- From yaronf@checkpoint.com Tue Mar 3 10:18:41 2009 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 3731E28C2F3 for ; Tue, 3 Mar 2009 10:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.214 X-Spam-Level: X-Spam-Status: No, score=-3.214 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 vMx-sDzP8Mi4 for ; Tue, 3 Mar 2009 10:18:40 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id C181328C2DD for ; Tue, 3 Mar 2009 10:17:43 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n23II916029867 for ; Tue, 3 Mar 2009 20:18:10 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 3 Mar 2009 20:18:09 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 3 Mar 2009 20:14:03 +0200 Thread-Topic: Issue #52: Pipelining: interop between supporting and non-supporting peers Thread-Index: AcmcK9ULi5jP1o4DQrKEONitocuDQQ== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6E@il-ex01.ad.checkpoint.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_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Eilex01adcheck_" MIME-Version: 1.0 Subject: [IPsec] Issue #52: Pipelining: interop between supporting and non-supporting peers 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, 03 Mar 2009 18:18:41 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Eilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yaron: 2.3: The first paragraph contains an apparent contradiction. It mentions th= at pipelining is done 'if the other endpoint has indicated its ability to h= andle such requests' and then goes on to describe how a pipelining implemen= tation can interoperate with a non-pipelining one. Which should be trivial = if the pipelining side knows what the other side is capable of. Paul: Not done, definitely worth discussing on the list. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Eilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yaron:

2.3: The first paragraph contains an apparent contradiction. It mentions that pipeli= ning is done 'if the other endpoint has indicated its ability to handle such requests' and then goes on to describe how a pipelining implementation can interoperate with a non-pipelining one. Which should be trivial if the pipelining side knows what the other side is capable of. =

Paul: Not done, definitely worth discussing on the list.

 

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Eilex01adcheck_-- From yaronf@checkpoint.com Tue Mar 3 10:20:08 2009 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 844C83A6C62 for ; Tue, 3 Mar 2009 10:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.241 X-Spam-Level: X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 xmm3RBnYvXsI for ; Tue, 3 Mar 2009 10:20:07 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 448A03A6C30 for ; Tue, 3 Mar 2009 10:20:07 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n23IIP18029921 for ; Tue, 3 Mar 2009 20:18:26 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 3 Mar 2009 20:18:25 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 3 Mar 2009 20:18:25 +0200 Thread-Topic: Issue #15: Message ID reset to 0 after IKE SA rekey Thread-Index: AcmcGlJeS4j2yO4+Sb2xLgrvgMgJ0A== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC73@il-ex01.ad.checkpoint.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_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC73ilex01adcheck_" MIME-Version: 1.0 Subject: [IPsec] Issue #15: Message ID reset to 0 after IKE SA rekey 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, 03 Mar 2009 18:20:08 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC73ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 2.2. Use of Sequence Numbers for Message ID The Message ID is a 32-bit quantity, which is zero for the IKE_SA_INIT mess= ages (including retries of the message due to responses such as COOKIE and = INVALID_KE_PAYLOAD {{ Clarif-2.2 }}), and incremented for each subsequent e= xchange. Tero: Add text: The Message ID is reset to zero also after IKE SA rekey for the new IKE SA. Paul: Not done. This is interesting, but should be discussed on the list. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC73ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

2.2. Use of Sequence Numbers for Message ID

The Message ID is a 32-bit quantity, which is zero for the IKE_SA_INIT messages (including retries of the message due to responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}), and incremented for each subsequent exchange.

Tero:

Add text:

The Message ID is reset to zero also after IKE SA rekey for the new IKE SA.

Paul: Not done. This is interesting, but should be discussed on the list. =

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC73ilex01adcheck_-- From yaronf@checkpoint.com Tue Mar 3 10:20:09 2009 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 5E3523A6C30 for ; Tue, 3 Mar 2009 10:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.965 X-Spam-Level: X-Spam-Status: No, score=-2.965 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 53pvmQOA8fK3 for ; Tue, 3 Mar 2009 10:20:06 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 18C3B3A6AAD for ; Tue, 3 Mar 2009 10:20:05 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n23IIK16029900 for ; Tue, 3 Mar 2009 20:18:20 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 3 Mar 2009 20:18:20 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 3 Mar 2009 20:17:05 +0200 Thread-Topic: Issue #58: Access control: add ref to IPsec architecture Thread-Index: AcmcLEH2wgCLVOXPTZOWLH5Rd1QXOg== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6F@il-ex01.ad.checkpoint.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_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Filex01adcheck_" MIME-Version: 1.0 Subject: [IPsec] Issue #58: Access control: add ref to IPsec architecture 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, 03 Mar 2009 18:20:09 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Filex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yaron: Sec. 3.5: this section is extremely liberal on what access control policies= people can implement, but that's too late to change now. However, we CAN a= t least add a reference to RFC 4301, Se= c. 4.4.3.1 ("PAD Entry IDs and Matching Rules") as was done in RFC 4945, pki4ipsec. Paul: Not done, take to the list. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Filex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yaron:

Sec. 3.5: this section is extremely liberal on what access control policies people ca= n implement, but that's too late to change now. However, we CAN at least add = a reference to RFC 4301, S= ec. 4.4.3.1 (“PAD Entry IDs and Matching Rules”) as was done in RFC 4945, pki4ipsec. <= /o:p>

Paul: Not done, take to the list.

 

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Filex01adcheck_-- From yaronf@checkpoint.com Tue Mar 3 10:20:09 2009 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 B40843A6C30 for ; Tue, 3 Mar 2009 10:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.267 X-Spam-Level: X-Spam-Status: No, score=-3.267 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Yv1Bmx1w+CSF for ; Tue, 3 Mar 2009 10:20:08 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 70A003A6C08 for ; Tue, 3 Mar 2009 10:20:08 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n23II316029839 for ; Tue, 3 Mar 2009 20:18:03 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 3 Mar 2009 20:18:03 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 3 Mar 2009 20:18:03 +0200 Thread-Topic: Issue #44: Remove IPv6 NBNS Thread-Index: AcmcG6ljSt9nszaQS5ei4CBtl7PxFQ== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6C@il-ex01.ad.checkpoint.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_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Cilex01adcheck_" MIME-Version: 1.0 Subject: [IPsec] Issue #44: Remove IPv6 NBNS 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, 03 Mar 2009 18:20:09 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Cilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sec. 3.15.1: o INTERNAL_IP6_NBNS - {{ Clarif-6.6 }} NetBIOS is not defined = for IPv6; therefore, INTERNAL_IP6_NBNS is also unspecified and is only reta= ined for compatibility with RFC 4306. I think there is no point of keeping the 'compatibility with RFC 4306' for feature that cannot be used. I would si= mply remove the whole INTERNAL_IP6_NBNS and mark it RESERVED. Paul: Not done. This should be discussed on the mailing list. Yaron: I support Tero on this. Input from IPv6 implementors would be most u= seful. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Cilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sec. 3.15.1: o INTERNAL_IP6_NBNS - {{ Clarif-6.6 }} NetBIOS is not defined for IPv6; therefore, INTERNAL_IP6_NBNS is also unspecified and is only retained for compatibility with RFC 4306<= /a>.

I think there is no point of keeping the 'compatibility with RFC 4306' for feature that = cannot be used. I would simply remove the whole INTERNAL_IP6_NBNS and mark it RESERVED.

Paul: Not done. This should be discussed on the mailing list.

Yaron: I support Tero on this. Input from IPv6 implement= ors would be most useful.

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6Cilex01adcheck_-- From yaronf@checkpoint.com Tue Mar 3 10:20:11 2009 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 2526228C2FA for ; Tue, 3 Mar 2009 10:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 U4TRU7Gupx97 for ; Tue, 3 Mar 2009 10:20:10 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 9AD8028C2DD for ; Tue, 3 Mar 2009 10:20:09 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n23IIR16029935 for ; Tue, 3 Mar 2009 20:18:28 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 3 Mar 2009 20:18:27 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 3 Mar 2009 20:18:27 +0200 Thread-Topic: Issue #35: INVALID_SPI: does the SPI determine the protocol (ESP/AH)? Thread-Index: AcmcGuuLfJ72zRtOTB2DUFgFk4rLQw== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC75@il-ex01.ad.checkpoint.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_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC75ilex01adcheck_" MIME-Version: 1.0 Subject: [IPsec] Issue #35: INVALID_SPI: does the SPI determine the protocol (ESP/AH)? 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, 03 Mar 2009 18:20:11 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC75ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1.5. Informational Messages outside of an IKE_SA ... {{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE INFORMAT= IONAL exchange when a node receives an ESP or AH packet with an invalid SPI= . The Notification Data contains the SPI of the invalid packet. This usuall= y indicates a node has rebooted and forgotten an SA. If this Informational = Message is sent outside the context of an IKE_SA, it should only be used by= the recipient as a 'hint' that something might be wrong (because it could = easily be forged). Tero: If the notification data is used for the SPI of the invalid packet, how can= the recipient of such notify know whether that SPI was for ESP or AH? As f= ar as I can see, it cannot, but I think it does not matter as SPIs are now = supposed to be unique (i.e. protocol is no loger include as key). Perhaps w= e should just note this fact here? Paul: Not done. This is interesting, but should be discussed on the list. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC75ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

1.5. Informational Messages outside of an IKE_SA

...

{{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE INFORMATION= AL exchange when a node receives an ESP or AH packet with an invalid SPI. The Notification Data contains the SPI of the invalid packet. This usually indicates a node has rebooted and forgotten an SA. If this Informational Message is sent outside the context of an IKE_SA, it should only be used by= the recipient as a 'hint' that something might be wrong (because it could easil= y be forged).

Tero:

If the notification data is used for the SPI of the invalid packet, how can the recipient of such notify know whether that SPI was for ESP or AH? As far as= I can see, it cannot, but I think it does not matter as SPIs are now supposed= to be unique (i.e. protocol is no loger include as key). Perhaps we should jus= t note this fact here?

Paul: Not done. This is interesting, but should be discussed on the list. =

 

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC75ilex01adcheck_-- From yaronf@checkpoint.com Tue Mar 3 10:20:13 2009 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 0307E28C2FA for ; Tue, 3 Mar 2009 10:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.304 X-Spam-Level: X-Spam-Status: No, score=-3.304 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 QDdQoFxI3rWh for ; Tue, 3 Mar 2009 10:20:11 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id CF7A028C2F2 for ; Tue, 3 Mar 2009 10:20:10 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n23IIP17029921 for ; Tue, 3 Mar 2009 20:18:26 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 3 Mar 2009 20:18:25 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 3 Mar 2009 20:18:24 +0200 Thread-Topic: Issue #6: DH proposal and INVALID_KE_PAYLOAD Thread-Index: AcmcGhJBhYxTylilRFakOH4OnG/jWA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC72@il-ex01.ad.checkpoint.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_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC72ilex01adcheck_" MIME-Version: 1.0 Subject: [IPsec] Issue #6: DH proposal and INVALID_KE_PAYLOAD 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, 03 Mar 2009 18:20:13 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC72ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/6 Yaron: Section 3.3.6, second paragraph: Assume a CREATE_CHILD_SA packet is receive= d with SA payload proposal 1 D-H=3D2 ... proposal 2 D-H=3D0 ... KE payload = D-H=3D2 ... Assume the responder wants to pick proposal number 2. Because t= he KE payload refers to D-H=3D2, the responder must return INVALID_KE_PAYLO= AD, event though the responder could just select proposal 2 and omit the KE= payload in the response. Paul: Sending INVALID_KE_PAYLOAD in this case certainly wasn't the intent, but yo= u're right that the text doesn't explicitly say this. Yaron: Should we say something like: An exception is the case where one of the proposals offered is for D-H grou= p NONE. In this case, the responder MUST ignore the initiator's KE payload = and omit the KE payload from the response. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC72ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/6<= /span>

 

Yaron:

Section 3.3.6, second paragraph: Assume a CREATE_CHILD_SA packet is received with S= A payload proposal 1 D-H=3D2 ... proposal 2 D-H=3D0 ... KE payload D-H=3D2 ..= . Assume the responder wants to pick proposal number 2. Because the KE payload refer= s to D-H=3D2, the responder must return INVALID_KE_PAYLOAD, event though the res= ponder could just select proposal 2 and omit the KE payload in the response. =

Paul:

Sending INVALID_KE_PAYLOAD in this case certainly wasn't the intent, but you're rig= ht that the text doesn't explicitly say this.

Yaron:

Should we say something like:

An exception is the case where one of the proposals offered is for D-H group N= ONE. In this case, the responder MUST ignore the initiator’s KE payload an= d omit the KE payload from the response.

 

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC72ilex01adcheck_-- From yaronf@checkpoint.com Tue Mar 3 10:20:13 2009 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 7E08528C2FF for ; Tue, 3 Mar 2009 10:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7ShVQsKdkdYn for ; Tue, 3 Mar 2009 10:20:12 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 09A0528C2DD for ; Tue, 3 Mar 2009 10:20:11 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n23IIP19029921 for ; Tue, 3 Mar 2009 20:18:27 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 3 Mar 2009 20:18:26 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 3 Mar 2009 20:18:26 +0200 Thread-Topic: Issue #17: Checking of the other peer's IKE SPI Thread-Index: AcmcGrigFobKfatMRA2+XtjQiNNOLw== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC74@il-ex01.ad.checkpoint.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_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC74ilex01adcheck_" MIME-Version: 1.0 Subject: [IPsec] Issue #17: Checking of the other peer's IKE SPI 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, 03 Mar 2009 18:20:13 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC74ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sec. 2.6: Unlike ESP and AH where only the recipient's SPI appears in the header of a= message, in IKE the sender's SPI is also sent in every message. Since the = SPI chosen by the original initiator of the IKE_SA is always sent first, an= endpoint with multiple IKE_SAs open that wants to find the appropriate IKE= _SA using the SPI it assigned must look at the I(nitiator) Flag bit in the = header to determine whether it assigned the first or the second eight octet= s. Tero: Our implementation originally only checked its own SPI half, and didn't ver= ify that the other ends SPI half didn't change. This was found out in the i= nterop, and we fixed it to check the other ends SPI also, but I wonder shou= ld we say one way or the other here? Also what SPI should the response have= , i.e. the SPIs from the request, or the SPIs from the original IKE SA crea= tion. I think it might be easier to just say, that implementations can use = their own SPI to find the IKE SA data, but MUST also check that the other e= nds SPI matches the SPIs stored with IKE SA data. Paul: Not done. This is interesting, but should be discussed on the list. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC74ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sec. 2.6:

 

Unlike ESP and AH where only the recipient's SPI appears in the header of a messag= e, in IKE the sender's SPI is also sent in every message. Since the SPI chosen= by the original initiator of the IKE_SA is always sent first, an endpoint with multiple IKE_SAs open that wants to find the appropriate IKE_SA using the S= PI it assigned must look at the I(nitiator) Flag bit in the header to determin= e whether it assigned the first or the second eight octets.

Tero:

Our implementation originally only checked its own SPI half, and didn't verify = that the other ends SPI half didn't change. This was found out in the interop, a= nd we fixed it to check the other ends SPI also, but I wonder should we say on= e way or the other here? Also what SPI should the response have, i.e. the SPI= s from the request, or the SPIs from the original IKE SA creation. I think it might be easier to just say, that implementations can use their own SPI to = find the IKE SA data, but MUST also check that the other ends SPI matches the SP= Is stored with IKE SA data.

Paul: Not done. This is interesting, but should be discussed on the list. =

 

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC74ilex01adcheck_-- From taddyhatty@nifty.com Tue Mar 3 19:53:30 2009 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 274813A683D for ; Tue, 3 Mar 2009 19:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.761 X-Spam-Level: X-Spam-Status: No, score=-0.761 tagged_above=-999 required=5 tests=[AWL=1.237, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, STOX_REPLY_TYPE=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 NwrZAMqYLo8F for ; Tue, 3 Mar 2009 19:53:28 -0800 (PST) Received: from userg500.nifty.com (userg500.nifty.com [202.248.238.80]) by core3.amsl.com (Postfix) with ESMTP id 020C63A698A for ; Tue, 3 Mar 2009 19:53:24 -0800 (PST) Received: from GATEWAY (nttkyo839039.tkyo.nt.ftth.ppp.infoweb.ne.jp [116.83.8.39])by userg500.nifty.com with SMTP id n243rQBl028559 for ; Wed, 4 Mar 2009 12:53:26 +0900 DomainKey-Signature: a=rsa-sha1; s=userg500; d=nifty.com; c=nofws; q=dns; h=message-id:reply-to:from:to:subject:date:organization: mime-version:content-type:content-transfer-encoding:x-priority: x-msmail-priority:x-mailer:x-mimeole; b=jUsYqVjeDfwtDw8G56czZZX55PGKfReuISgrdwUnB3uV2tkib2255pavV2MO6WMpr ZFwZo3P1YgeDx0WVM8eng== X-Nifty-SrcIP: [116.83.8.39] Message-ID: <375E6B2637BD4904B91B69F04B131B82@GATEWAY> From: "Tadayuki Abraham HATTORI" To: Date: Wed, 4 Mar 2009 12:53:26 +0900 Organization: TaddyHatty MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: [IPsec] Proposal of democratic communication protocols, considering extensions of TCP/IP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Tadayuki Abraham HATTORI List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 03:53:30 -0000 Dear professionals and experts, The Digital Money System based upon numerical prosessor, Operationg Systemand the TCP/IP networking has a critial social security hole. It may be a social security issue about communication technology. It's a proposal of democratic communication protocols, considering extensions of TCP/IP. I'm looking for the discussion area about the communication technology for aceelrating democratic activities. In other words, the discussion to create new RFC for democratic communication protocols considering the extensions of TCP/IP, and the central controlled information systems. Sincerely. Please give me recommendation or advices. Regards, --- Abraham TaddyHatty taddyhatty@acm.org ---------- Internet Draft for extension of the fundamental concept of TCP/IP Donation for Political Party and The Digital Money System The Critical Social Security Hole of the Numerical Computer Architecture, Operating System and The TCP/IP Networking Abraham TADDYHATTY taddyhatty@acm.org T.B.D 1. Introduction The present computer architecture was originally invented as a numerical calculater. As you may know, the main circuit of central pocesser unit is indeed an arithmetic calculater. It was not created as an accelerator of interaction of humanities. Of cource, many core processor is also. As you may know, the CPU of computer is contorolled by Operationg System. And the concept of Operationg System was originally invented for both abstraction of hardware and resource management. It is originally invented by the programmer's point of view, so, the role of Operationg System can be said to be just making programming efficiently. Generally, in Operationg System, the power of controlling information is centrally concentrated. Is it adespotism? Is there no need to consider the separation of the power? And also, the TCP/IP networking was originally designed as a military network. It was invented for the objective of efficient communication in troop or army, not for optimization of democracy. There is no need to say, grasping and controlling information among people is a kind of power. In designing TCP/IP networking, the meaning of separation of the power among citizen was not considered. In modern nations, why the power is separated? for example, justice, legislation and administration. What is the principle of separation of the power? Does the scientific theorem of separation of the power exist ? Who should have the power grasping information among people? Historically both Operating System and the TCP/IP networking was not designed for optimization of democratic activities, so, using Operating System and the TCP/IP networking, the power of controling information will be centrally concentrated, and putting democracy out of balance. By the way, generally, we have two choices for understanding a nation. One is that a nation is considered as a set of organizations, and people always should belong to some organization. And another is that a nation is considered as a set of people or family, and organizations is just a method for people not a objective of people. Reminding and considering an idea of democratic egalitarianism, the correct answer is the later, a nation should be considered as a set of people. Any organization should be considered as just a method for people, not a objective for people. Using Operationg System and the TCP/IP networking as bridges of communication of humanities, the power to control information will be centrally gathered,and so, the companies or public organizations centric information system is tend to be constructed. Because the power of controlling information is gathered to managers of companies, and the managers of campanies are easy to modify or hide information of social system. For example, people can't check the duration for political parties by huge companies with the digital money through the TCP/IP networking. It would be difficult to check evil informatic activities by managers of campanies. As I mentioned above, a nation should be considered as a set of citizen, not a set of military organization, the trend will put democracy out of balance. Because democratic activities depends upon intensive gathering of people's decision making with correct balanced distributin of information. Generally, in a democratic nation, each people is both value judger and decision maker. Most of all, in the digital money system based upon Operating System and the TCP/IP networking, duration for political party by managers of large campanies can't be publically controlled. Because the current digital money system is based upon OS and the TCP/IP networking, the power to contol information is centrally gathered to managers. The organization oriented information system bring putting a national democracy out of balance. Basically, for public infrastructure such as digital money system, Operating System and the TCP/IP networking should not be used. We must modify the specifications, I think. Should we choose the central controlled information system in order to construct public digital money system ? Is it a correct choice? We should remember the faces of the people who selling digital money system. We should remind the faces of th people who promoting numerical computer network for social infrastructures. What ware thay saying ? Was their thought is sufficient? Was their insight is enough? Who was showing the academic direction and the trend of information science? There is no need to say, high level decision making is always going to affect the future rewards of people and the satisfaction of nation. When we discuss the communication technology for optimization of democratic activities, we should truely be careful of the history and the culture of each nations, and the deep insight will be required. So, I propose a concept of academic criminals. The concept is created for judging high level decision making in academic opinions and activities. Generally, academic opinions and activities can't be reviced by current social system such as administration justice and legislation. Because the present social systems always should be focusing the present problems, not focusing the far future of civilization. The intellectual method of prediction of the future should be included in academic activities. Historically, our civilization have been formed with characters, languages, mathematics and any culture based upon both paper and ink which have been used for a long time. As you may know, these tools are now going to be replaced with electro-maginetic-optical devices. It means that renovation of civilization is indeed under going. The concept of Academic Criminals will be useful for keeping general dicision making of direction of academic activities and opinions in balance, I think. Ultimate goal of this matter is finding out the theorem for how to locate the power to control information among the communication road of the people, where the power to control information should be located, and how to modify the location of the power to control information. And, according to the theorem, the specifications of Operationg System and the TCP/IP networking should be modified, I think. Generally, democratic systems can't be constructed by capitalism. It would be formed depending upon the idea or the theorem, I beleave. Sincerely. --- Abraham TaddyHatty taddyhatty@acm.org From paul.hoffman@vpnc.org Tue Mar 3 20:18:54 2009 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 B794D3A6A66 for ; Tue, 3 Mar 2009 20:18:54 -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 BNDN8Sr3HAnS for ; Tue, 3 Mar 2009 20:18:54 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A59FA3A6A19 for ; Tue, 3 Mar 2009 20:18:53 -0800 (PST) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n244JIZ4004044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 21:19:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <375E6B2637BD4904B91B69F04B131B82@GATEWAY> References: <375E6B2637BD4904B91B69F04B131B82@GATEWAY> Date: Tue, 3 Mar 2009 20:19:16 -0800 To: Tadayuki Abraham HATTORI From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] Proposal of democratic communication protocols, considering extensions of TCP/IP 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, 04 Mar 2009 04:18:54 -0000 Wearing my co-chair hat: This proposal is not appropriate for the IPsecME Working Group at this time. I propose that you write an actual Internet Draft and set up a mailing list for your own discussion. Feel free to tell this list when there are new versions of your draft and ask for input, but discussion of your draft needs to be on a different list. --Paul Hoffman, Director --VPN Consortium From kivinen@iki.fi Wed Mar 4 04:39:21 2009 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 70DA83A6C77 for ; Wed, 4 Mar 2009 04:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 KtUxuUmdblNj for ; Wed, 4 Mar 2009 04:39:20 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8F83A685B for ; Wed, 4 Mar 2009 04:39:19 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n24CdeAB001679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 14:39:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n24CdehJ024956; Wed, 4 Mar 2009 14:39:40 +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: <18862.30348.285195.965651@fireball.kivinen.iki.fi> Date: Wed, 4 Mar 2009 14:39:40 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6B@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6B@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 4 min Cc: "ipsec@ietf.org" Subject: [IPsec] Issue #42: Improve example of multiple proposals 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, 04 Mar 2009 12:39:21 -0000 Yaron Sheffer writes: > Yaron: a new proposal example would be appreciated! I provide replacement text at in the thread starting at 2008-09-23 15:52 (message id <18648.59003.22895.803651@fireball.kivinen.iki.fi>). here is link to the thread: http://thread.gmane.org/gmane.ietf.ipsec/8317 -- kivinen@iki.fi From sumita@huawei.com Wed Mar 4 05:12:09 2009 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 CC5E93A6C8B for ; Wed, 4 Mar 2009 05:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.365 X-Spam-Level: * X-Spam-Status: No, score=1.365 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 G81I+95Uxx-Z for ; Wed, 4 Mar 2009 05:12:09 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 83DE83A68D4 for ; Wed, 4 Mar 2009 05:12:08 -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 <0KFZ003RUGOMX7@szxga03-in.huawei.com> for ipsec@ietf.org; Wed, 04 Mar 2009 21:12:23 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFZ0054MGOMC0@szxga03-in.huawei.com> for ipsec@ietf.org; Wed, 04 Mar 2009 21:12:22 +0800 (CST) Received: from HTIPL60836 ([10.18.24.99]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KFZ005OMGOLVI@szxml05-in.huawei.com> for ipsec@ietf.org; Wed, 04 Mar 2009 21:12:22 +0800 (CST) Date: Wed, 04 Mar 2009 18:42:21 +0530 From: sumit To: ipsec@ietf.org Message-id: <000001c99cca$dacdb150$6318120a@china.huawei.com> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_aUrl9LC5TZnWmtVmD5VkpA)" Thread-index: AcmcytotZt2aXqk4QcWFsr8BDgeg4Q== X-Mailman-Approved-At: Wed, 04 Mar 2009 08:02:23 -0800 Subject: [IPsec] Question on Hash and CERT Bundle X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sumita@huawei.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 13:28:10 -0000 This is a multi-part message in MIME format. --Boundary_(ID_aUrl9LC5TZnWmtVmD5VkpA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, RFC 4306 mentions two Certificate encoding type Hash and URL of X.509 certificate(12) Hash and URL of X.509 bundle(13). Can anyone clarify when is Hash and URL of X.509 certificate(12) used and when to use Hash and URL of X.509 bundle(13)? Can there be CRL (Certificate revocation list) present in the CERT Bundle? With warm regards, Sumit Agarwal Huawei Technologies India (P) Ltd **************************************************************************** ******************************************* 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! --Boundary_(ID_aUrl9LC5TZnWmtVmD5VkpA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

 

RFC 4306 mentions two Certificate encoding type =

Hash and URL of X.509 certificate(12)

Hash and URL of X.509 bundle(13).

 

Can = anyone clarify when is Hash and URL of X.509 = certificate(12) used and when to use Hash and URL of = X.509 bundle(13)?

 

Can there be CRL (Certificate revocation list) present in = the CERT Bundle?

 

 

With warm regards,

Sumit Agarwal

Huawei Technologies India (P) Ltd

**********************************************= *************************************************************************=

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!

 

 

--Boundary_(ID_aUrl9LC5TZnWmtVmD5VkpA)-- From paul.hoffman@vpnc.org Wed Mar 4 10:00:57 2009 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 A74743A6BA7 for ; Wed, 4 Mar 2009 10:00:57 -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 CTGD+PpfcOEv for ; Wed, 4 Mar 2009 10:00:56 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 33B163A698D for ; Wed, 4 Mar 2009 10:00:55 -0800 (PST) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n24I1IDW053212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 11:01:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18862.30348.285195.965651@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6B@il-ex01.ad.checkpoint.com> <18862.30348.285195.965651@fireball.kivinen.iki.fi> Date: Wed, 4 Mar 2009 10:01:17 -0800 To: Tero Kivinen , Yaron Sheffer From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Issue #42: Improve example of multiple proposals 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, 04 Mar 2009 18:00:57 -0000 At 2:39 PM +0200 3/4/09, Tero Kivinen wrote: >Yaron Sheffer writes: >> Yaron: a new proposal example would be appreciated! > >I provide replacement text at in the thread starting at 2008-09-23 >15:52 (message id <18648.59003.22895.803651@fireball.kivinen.iki.fi>). > >here is link to the thread: http://thread.gmane.org/gmane.ietf.ipsec/8317 You also followed it up later with a much longer example that I thought confused things. I'm fine with the idea of taking out the "ESP or AH" part; I'm OK with your replacement if the rest of the WG is. Do people find the following reasonable? The Proposal structure contains within it a Proposal # and an IPsec protocol ID. Each structure MUST have a proposal number that is one greater than the previous structure. The first Proposal in the initiator's SA payload MUST have a Proposal # of 1. The main reason to use multiple proposals is when using combined-mode ciphers. Combined-mode ciphers include both integrity and encryption in single encryption algorithm. Because of this, it is not allowed to have combined mode ciphers with an another integrity algorithm, and thus a proposal MUST NOT have any integrity algorithms other than NONE. If the initiator wants to propose both combined-mode ciphers and normal ciphers, it must include two proposals. One proposal will have all combined-mode ciphers and no integrity algorithm. The other proposal will have all non-combined-mode ciphers and all the allowed integrity algorithms. For example, such proposal could have two proposal structures, one for ESP with ENCR_AES-CCM_8, ENCR_AES-CCM_12, and ENCR_AES-CCM_16 as Proposal #1 and one for ESP with ENCR_AES_CBC, ENCR_3DES, AUTH_AES_XCBC_96, and AUTH_HMAC_SHA1_96 as Proposal #2. --Paul Hoffman, Director --VPN Consortium From yaronf@checkpoint.com Wed Mar 4 14:00:53 2009 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 9481C3A6AB7 for ; Wed, 4 Mar 2009 14:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[AWL=-0.235, 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 kBDEXj3zKuOw for ; Wed, 4 Mar 2009 14:00:46 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 612D03A6AB4 for ; Wed, 4 Mar 2009 14:00:46 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D96F62CC002; Thu, 5 Mar 2009 00:01:13 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id AAF942CC001; Thu, 5 Mar 2009 00:01:12 +0200 (IST) X-CheckPoint: {49AEF9C2-0-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n24M1B16012204; Thu, 5 Mar 2009 00:01:12 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 5 Mar 2009 00:01:11 +0200 From: Yaron Sheffer To: Paul Hoffman , Tero Kivinen Date: Thu, 5 Mar 2009 00:01:10 +0200 Thread-Topic: [IPsec] Issue #42: Improve example of multiple proposals Thread-Index: Acmc8zrt5uDoMqm4R7KVF5lm8GDa8wAIT7Cw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EE06@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6B@il-ex01.ad.checkpoint.com> <18862.30348.285195.965651@fireball.kivinen.iki.fi> In-Reply-To: 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: "ipsec@ietf.org" Subject: Re: [IPsec] Issue #42: Improve example of multiple proposals 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, 04 Mar 2009 22:00:53 -0000 Editorial: in "Combined-mode ciphers include both integrity and encryption = in single encryption algorithm", strike out the second "encryption" or repl= ace it by "cryptographic". Thanks, Yaron > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Wednesday, March 04, 2009 20:01 > To: Tero Kivinen; Yaron Sheffer > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Issue #42: Improve example of multiple proposals >=20 > At 2:39 PM +0200 3/4/09, Tero Kivinen wrote: > >Yaron Sheffer writes: > >> Yaron: a new proposal example would be appreciated! > > > >I provide replacement text at in the thread starting at 2008-09-23 > >15:52 (message id <18648.59003.22895.803651@fireball.kivinen.iki.fi>). > > > >here is link to the thread: http://thread.gmane.org/gmane.ietf.ipsec/831= 7 >=20 > You also followed it up later with a much longer example that I thought > confused things. >=20 > I'm fine with the idea of taking out the "ESP or AH" part; I'm OK with > your replacement if the rest of the WG is. Do people find the following > reasonable? >=20 > The Proposal structure contains within it a Proposal # and an IPsec > protocol ID. Each structure MUST have a proposal number that is one > greater than the previous structure. The first Proposal in the > initiator's SA payload MUST have a Proposal # of 1. The main reason > to use multiple proposals is when using combined-mode ciphers. > Combined-mode ciphers include both integrity and encryption in single > encryption algorithm. Because of this, it is not allowed to have > combined mode ciphers with an another integrity algorithm, and thus a > proposal MUST NOT have any integrity algorithms other than NONE. If > the initiator wants to propose both combined-mode ciphers and normal > ciphers, it must include two proposals. One proposal will have all > combined-mode ciphers and no integrity algorithm. The other proposal > will have all non-combined-mode ciphers and all the allowed integrity > algorithms. For example, such proposal could have two proposal > structures, one for ESP with ENCR_AES-CCM_8, ENCR_AES-CCM_12, and > ENCR_AES-CCM_16 as Proposal #1 and one for ESP with ENCR_AES_CBC, > ENCR_3DES, AUTH_AES_XCBC_96, and AUTH_HMAC_SHA1_96 as Proposal #2. >=20 > --Paul Hoffman, Director > --VPN Consortium >=20 > Scanned by Check Point Total Security Gateway. >=20 > Scanned by Check Point Total Security Gateway. Email secured by Check Point From gregory.ietf@gmail.com Thu Mar 5 13:27:33 2009 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 CCAF83A68F7 for ; Thu, 5 Mar 2009 13:27:33 -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 Aq78qPtJpJGN for ; Thu, 5 Mar 2009 13:27:32 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id B14403A6821 for ; Thu, 5 Mar 2009 13:27:32 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so101151ywh.49 for ; Thu, 05 Mar 2009 13:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=J2SV2NvSyX7NTPHAmACDmnqgScpCmxJf0IJjxSs4NRQ=; b=GRuMHuSSHM7RMDMj/X8uwKEjXgjfFe21SmBen4UVuEyc8wvH6bdwpfcMyFOw2UOSJh 1D+zAnHHQRcX2ul9o6wp3ZyMHHsOmLT62d/SqJOLhDP6jy/8mYYW75350y3TWTLCpDdH n6tc8mZpz9TaCnmckJBEBAzLmjrCocSvPwdwU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kUvI3xESYz8dK4UXGOjSi3uziBFye/itOLcbzW2fxW4VSC8J14sEe5ks1Fcl6OfA9B 1CvQXTBbFj0zTnx5EsEsV9jYbPVYLOsPIx85mSEej3iZ0DPhYd1S/F+5fuLGVtfC4YyS IFE7vuwxyRvkUimIy9WIzJ4OZTmpye+z0B9oQ= MIME-Version: 1.0 Received: by 10.231.14.196 with SMTP id h4mr474005iba.36.1236288482032; Thu, 05 Mar 2009 13:28:02 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Mar 2009 13:28:01 -0800 Message-ID: From: Gregory Lebovitz To: "Grewal, Ken" Content-Type: multipart/alternative; boundary=0003255762cacfbbe2046465d765 Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Potential way forward for IPsecME on ESP-NULL 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, 05 Mar 2009 21:27:33 -0000 --0003255762cacfbbe2046465d765 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I support this approach to moving forward. - Gregory -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks On Wed, Feb 18, 2009 at 8:05 AM, Grewal, Ken wrote: > Hi Paul, > I have no objections to this approach moving forward. > > Thanks, > - Ken > > > >-----Original Message----- > >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > >Paul Hoffman > >Sent: Tuesday, February 17, 2009 6:56 AM > >To: IPsecme WG > >Subject: [IPsec] Potential way forward for IPsecME on ESP-NULL > > > >Wearing our one-size-fits-all shared co-chair hat, Yaron and I propose > the > >following. > > > >- Both documents can continue forwards, adding the heuristics document as > a > >WG item. Pasi has agreed that the current WG charter allows this. > > > >- The heuristics document would eventually be published as an > Informational > >RFC. WESP would be the protocol produced by the WG. > > > >- The purpose of the heuristics document would be to help deep-inspection > >firewall vendors find ESP-NULL traffic that is not encapsulated with WESP. > >It is considered an educational document for firewall developers who might > >want to do heuristic checks on ESP traffic. Firewalls might want to do > this > >until WESP is widely deployed, or even after wide deployment if sufficient > >firewall resources are available in order to check for ESP-NULL that is > not > >yet wrapped in WESP. > > > >- Each document talks about the applicability of its own content, while > >referring to the other document. > > > >Are there any strong objections to this plan? > > > >--Paul Hoffman, Director > >--VPN Consortium > >_______________________________________________ > >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 > --0003255762cacfbbe2046465d765 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I support this approach to moving forward. - Gregory
=A0
--
----
IETF related email from
Gregory M. Lebovitz
Junip= er Networks

On Wed, Feb 18, 2009 at 8:05 AM, Grewal, Ken <ken.grewal@intel= .com> wrote:
Hi Paul,
I have no objections= to this approach moving forward.

Thanks,
- Ken


>-----Original Message-----
>From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behal= f Of
>Paul Hoffman
>Sent: Tuesday, February 17, 2009 6:56 AM
>To:= IPsecme WG
>Subject: [IPsec] Potential way forward for IPsecME on ES= P-NULL
>
>Wearing our one-size-fits-all shared co-chair hat, Ya= ron and I propose the
>following.
>
>- Both documents can= continue forwards, adding the heuristics document as a
>WG item. Pas= i has agreed that the current WG charter allows this.
>
>- The heuristics document would eventually be published as an I= nformational
>RFC. WESP would be the protocol produced by the WG.
= >
>- The purpose of the heuristics document would be to help deep-= inspection
>firewall vendors find ESP-NULL traffic that is not encapsulated with WE= SP.
>It is considered an educational document for firewall developers= who might
>want to do heuristic checks on ESP traffic. Firewalls mig= ht want to do this
>until WESP is widely deployed, or even after wide deployment if suffici= ent
>firewall resources are available in order to check for ESP-NULL = that is not
>yet wrapped in WESP.
>
>- Each document talk= s about the applicability of its own content, while
>referring to the other document.
>
>Are there any strong ob= jections to this plan?
>
>--Paul Hoffman, Director
>--VPN= Consortium
>_______________________________________________
>I= Psec mailing list
>IPsec@ietf.org
>https://www.= ietf.org/mailman/listinfo/ipsec
____________________________________= ___________
IPsec mailing list
IPsec@ietf.org<= br>https://www.ietf.org/mailman/listinfo/ipsec




--0003255762cacfbbe2046465d765-- From dvijay@gmail.com Thu Mar 5 16:53:27 2009 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 38E193A69D6 for ; Thu, 5 Mar 2009 16:53:27 -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 na9uaOSLbDlf for ; Thu, 5 Mar 2009 16:53:26 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 37F953A69B0 for ; Thu, 5 Mar 2009 16:53:26 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so226901wfd.31 for ; Thu, 05 Mar 2009 16:53:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=A86mcYjAvvoNcwMs/ZP/xHoKsUA5KMlq7F4/14XnV3A=; b=gja4n2mz9zzkzFF8svcMhmTv23V0aIH96xicciOL4xEpsnBsRkPVmnhMdss+00xnP2 oT3JnL3+i+G7zTW/4BPvbB1YWLCxwkzyrgL0h8q0H8W34bkaNXC/mvWBNn7A/8/y7E/p 6c60c10rf+whUVoozKIFQrG8hlgL6gN8ZTeus= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=GS71+q54ePaWS1UxeRCCcMIoLn6txxoMH5XXPzwNdFy9nkrkr13wzAuaJDqDy+nyV8 aDDcJZWyguWGk2NJKH7K0rN6J4mVnkvZl+yeZdRhHh2T/0DR4ZfKjVNiQsaO+2xzI2cy S2u/70Zbg8h64ucj4A673oyJ3ghTlaNIFIIo4= MIME-Version: 1.0 Received: by 10.142.173.8 with SMTP id v8mr799136wfe.55.1236300836269; Thu, 05 Mar 2009 16:53:56 -0800 (PST) Date: Thu, 5 Mar 2009 16:53:56 -0800 Message-ID: From: Vijay Devarapalli To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPsecme WG , Yoav Nir , paul.hoffman@vpnc.org Subject: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04) 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, 06 Mar 2009 00:53:27 -0000 Hello, There at least three people who think that the IKE_AUTH response message should itself contain the REDIRECT payload. I went through the email exchange between Fan and Tero. There was no new information that came out of that discussion for me to make this change in the draft. Does any one else have an opinion? Otherwise I suggest the WG chairs to make a call on this. Both solutions, 1) sending a REDIRECT payload in the IKE_AUTH response 2) sending a NO_ADDITIONAL_SAS in the IKE_AUTH response followed by a REDIRECT message, would work. Vijay 2009/2/26 Yaron Sheffer : > > > I join Yoav and Fan in supporting this draft, even in its current form. H= owever I also agree with them that the protocol will be cleaner (and subseq= uently, implementations will be simpler), if we allow redirection in IKE_AU= TH, specifically only in the last message of the exchange. > > Thanks, > =C2=A0 =C2=A0 =C2=A0 =C2=A0Yaron > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf O= f >> fan zhao >> Sent: Thursday, February 26, 2009 3:58 >> To: Yoav Nir >> Cc: IPsecme WG >> Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 >> >> Hi, >> >> I am ok with moving this draft forward. However, I strongly prefer >> allowing >> redirection in the IKE_AUTH as well. As you may know, last week >> on the 3GPP SA2 meeting, the SA2 working group adopted the solution >> that uses the IKEv2 signaling message for gateway redirection/reallocati= on >> when the mobile terminal performs attach. >> >> Sincerely, >> fan >> >> >> >> On Wed, Feb 25, 2009 at 5:02 AM, Yoav Nir wrote: >> > I support advancing this. >> > >> > I preferred allowing the redirect in IKE_AUTH as well, but it seems li= ke >> the group consensus went against that. >> > >> > One textual comment: since we have section 7 describing a symmetric ca= se >> (redirect by either peer), section 6.1 should be chagned to reflect that >> the REDIRECT_SUPPORTED may be in either or both of the request and reply >> of the Initial exchange, and perhaps a picture can be added to section 7= . >> > >> > Even without this, the text is clear and useful. >> > >> >> -----Original Message----- >> >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] >> >> On Behalf Of Yaron Sheffer >> >> Sent: Wednesday, February 25, 2009 2:34 PM >> >> To: IPsecme WG >> >> Subject: Re: [IPsec] WG Last Call: >> >> draft-ietf-ipsecme-ikev2-redirect-04 >> >> >> >> This is a reminder that we are having a last call for the >> >> Redirect document. Even if you support advancing this >> >> document, but have no other comments, please state your >> >> opinion on the list. >> >> >> >> Thanks, >> >> =C2=A0 =C2=A0 =C2=A0 Yaron >> >> >> >> > -----Original Message----- >> >> > From: ipsec-bounces@ietf.org >> >> [mailto:ipsec-bounces@ietf.org] On Behalf >> >> > Of Yaron Sheffer >> >> > Sent: Monday, February 16, 2009 11:46 >> >> > To: IPsecme WG >> >> > Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 >> >> > >> >> > This is a 2 week working group last call for >> >> draft-ietf-ipsecme-ikev2- >> >> > redirect-04. The target status for this document is >> >> Proposed Standard. >> >> > >> >> > Please send your comments to the ipsec list by March 2, 2009, as >> >> > follow- ups to this message. >> >> > >> >> > Please clearly indicate the position of any issue in the Internet >> >> > Draft, and if possible provide alternative text. Please >> >> also indicate >> >> > the nature or severity of the error or correction, e.g. major >> >> > technical, minor technical, nit, so that we can quickly judge the >> >> > extent of problems with the document. >> >> > >> >> > The document can be accessed here: >> >> > http://tools.ietf.org/html/draft-ietf- >> >> > ipsecme-ikev2-redirect-04. >> >> > >> >> > Please note that one issue is currently open against this draft: >> >> > http://tools.ietf.org/wg/ipsecme/trac/ticket/82. >> >> > >> >> > Thanks, >> >> > =C2=A0 =C2=A0 Yaron >> >> > >> >> > Email secured by Check Point >> >> > _______________________________________________ >> >> > IPsec mailing list >> >> > IPsec@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/ipsec >> >> > >> >> > Scanned by Check Point Total Security Gateway. >> >> > >> >> > Scanned by Check Point Total Security Gateway. >> >> >> >> Email secured by Check Point >> >> _______________________________________________ >> >> IPsec mailing list >> >> IPsec@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> >> Scanned by Check Point Total Security Gateway. >> >> >> >> Scanned by Check Point Total Security Gateway. >> >> >> > Email secured by Check Point >> > _______________________________________________ >> > 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 >> >> Scanned by Check Point Total Security Gateway. >> >> Scanned by Check Point Total Security Gateway. > > Email secured by Check Point > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From dvijay@gmail.com Thu Mar 5 17:25:33 2009 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 B30023A6AFA for ; Thu, 5 Mar 2009 17:25:33 -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, J_CHICKENPOX_23=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 DeIFrP02zXum for ; Thu, 5 Mar 2009 17:25:33 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id E59B03A68F7 for ; Thu, 5 Mar 2009 17:25:32 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so240450wfd.31 for ; Thu, 05 Mar 2009 17:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YPGMXLyZROPr9LpfR8biUSGmInmB244EIeqPNZoSP6M=; b=aD7di7Ny2ptyWBL5BAfNGCNXdIUY7/WSnVfnw4F3+1CBizdM3PZjwqXFsETvI+Px+E 7kEtdIljVNr6fdtSUyRQeCS7s9hYZOUB/P1iPhI0EmTGmwV2vJfYu5XbdcbGV4Ns9EYK 0UqIOsjNps+lTMZE9dO+tJ/l9gJeC23Ukjn60= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GiHnQVFLJhVEgP3V0Yzy9x5fe55SvHdBZg/geDqoT90eXpaa7f0JrS0gug6bfprAzb ccaKYNWZgQLewud7pn12V4sr8islFe0pqSzPwOgJK7QMLlcO6GwAg1rAxVvKPkyHzzlx LQ+2MFZwh/wLRtyw/73pVUWMzirmD+3KdfXS4= MIME-Version: 1.0 Received: by 10.142.50.6 with SMTP id x6mr807602wfx.218.1236302763049; Thu, 05 Mar 2009 17:26:03 -0800 (PST) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 5 Mar 2009 17:26:03 -0800 Message-ID: From: Vijay Devarapalli To: Pasi.Eronen@nokia.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, rfgraveman@gmail.com Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 06 Mar 2009 01:25:33 -0000 Hi Pasi, Responding to the minor comments first... On Mon, Mar 2, 2009 at 12:04 PM, wrote: > Minor clarifications and nits: > > - Section 4 says "If an anycast address is returned in response to DNS > resolution of an FQDN, the IKEv2 transaction between the VPN client > and the VPN gateway is slightly modified." It seems the transaction is > actually *not* modified at all -- it's exactly identical to the > unicast case (and VPN client can't tell which case occurred)? Fixed this. What I wanted to say was that the IKE_SA_INIT might get routed to a different VPN gateway that is part of the anycast group. The client is of course not aware of this. > - Section 5: I don't think treating REDIRECT+"sufficient time period" > as implicit delete is a good idea. RFC 4306 requires sending delete > payloads whenever possible, and if the VPN GW wants to close the > IKE_SA, it could include the Delete payload in the same message as the > REDIRECT notification... The draft currently requires the client to delete the SA once it receives the REDIRECT message from the gateway. I do not want the gateway to delete the SA right away. The gateway should allow the client to setup the necessary security associations with the new gateway before deleting the SA with the existing gateway, if that is what the client wants to do. The current text is to handle the case where for some reason the gateway does not receive the DELETE payload from the client. Note that this shouldn't happen normally. The gateway garbage collects the SA after a certain time period. I don't think the gateway needs to send a DELETE payload at this point. > - Section 6.1/6.2/6.3: should say that Protocol ID is set to zero. Fixed. > - Section 6.2 says this message is included in IKE_SA_INIT response; > also INFORMATIONAL request, right? Thanks for catching. This is from the initial versions where the REDIRECT was only happening during the IKE_SA_INIT exchange. Fixed this. > - Section 7: I'm a bit skeptical if this actually works. The rest of > the document certainly does not describe how it would work, and in > many places, assumes the client-gateway case (e.g. Section 6.1 says > REDIRECT_SUPPORTED is only sent in initial IKE_SA_INIT request, so the > responder can't actually tell the initiator it supports this feature, > etc.) I am fine with restricting the scope as Tero suggested. My interest has always been in client-gateway scenarios anyway. I am cc'ing Rich Graveman who wanted this feature. Rich? Vijay From yaronf@checkpoint.com Thu Mar 5 23:40:39 2009 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 BF75A3A68A4 for ; Thu, 5 Mar 2009 23:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.023 X-Spam-Level: X-Spam-Status: No, score=-3.023 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, J_CHICKENPOX_23=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 HP3iL+3G49AS for ; Thu, 5 Mar 2009 23:40:38 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 821853A67D7 for ; Thu, 5 Mar 2009 23:40:38 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n2670a16003580; Fri, 6 Mar 2009 09:00:37 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Fri, 6 Mar 2009 09:00:36 +0200 From: Yaron Sheffer To: Vijay Devarapalli , "Pasi.Eronen@nokia.com" Date: Fri, 6 Mar 2009 09:00:35 +0200 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 Thread-Index: Acmd+oetXNWh/39LScSHjERJpR5xYAALJ36Q Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EFC5@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: 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: "ipsec@ietf.org" , "rfgraveman@gmail.com" Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 06 Mar 2009 07:40:39 -0000 Hi, I have a slight preference to keeping the protocol symmetric. But even if w= e choose not to do that, I think Tero's text (quoted below) leaves too much= room for interpretation. --- 7. Use of the Redirect Mechanism between IKEv2 Peers The Re-direct mechanism described in this document is mainly intended for use in client-gateway scenarios. However, the mechanism can also be used between any two IKEv2 peers, but this protocol is asymmetric, meaning that only the responder can redirect initiator to some other server. --- The protocol supports using an Informational exchange for redirect at any t= ime during the SA lifetime, and this is inherently symmetric. And of course= , following an IKE SA rekey, the initiator/responder roles might change. If= we go for the restricted option, the new text should cover both of these i= ssues. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Vijay Devarapalli > Sent: Friday, March 06, 2009 3:26 > To: Pasi.Eronen@nokia.com > Cc: ipsec@ietf.org; rfgraveman@gmail.com > Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 >=20 > Hi Pasi, >=20 [snip] >=20 > > - Section 7: I'm a bit skeptical if this actually works. The rest of > > the document certainly does not describe how it would work, and in > > many places, assumes the client-gateway case (e.g. Section 6.1 says > > REDIRECT_SUPPORTED is only sent in initial IKE_SA_INIT request, so the > > responder can't actually tell the initiator it supports this feature, > > etc.) >=20 > I am fine with restricting the scope as Tero suggested. My interest > has always been in client-gateway scenarios anyway. I am cc'ing Rich > Graveman who wanted this feature. Rich? >=20 > Vijay > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. >=20 > Scanned by Check Point Total Security Gateway. From kivinen@iki.fi Fri Mar 6 05:42:42 2009 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 F12F83A6C22 for ; Fri, 6 Mar 2009 05:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 O5ARpClPg05F for ; Fri, 6 Mar 2009 05:42:42 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 02E8B28C279 for ; Fri, 6 Mar 2009 05:42:39 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n26Dh56B009762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2009 15:43:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n26Dh5qr014486; Fri, 6 Mar 2009 15:43:05 +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: <18865.10345.214381.996149@fireball.kivinen.iki.fi> Date: Fri, 6 Mar 2009 15:43:05 +0200 From: Tero Kivinen To: Vijay Devarapalli In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, rfgraveman@gmail.com Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 06 Mar 2009 13:42:43 -0000 Vijay Devarapalli writes: > The draft currently requires the client to delete the SA once it > receives the REDIRECT message from the gateway. I do not want the > gateway to delete the SA right away. The gateway should allow the > client to setup the necessary security associations with the new > gateway before deleting the SA with the existing gateway, if that is > what the client wants to do. The current text is to handle the case > where for some reason the gateway does not receive the DELETE payload > from the client. Note that this shouldn't happen normally. The gateway > garbage collects the SA after a certain time period. I don't think the > gateway needs to send a DELETE payload at this point. I disagree with that. If gateway decides to delete the IKE SA, it needs to send DELETE payload in that case. The only case where you do not send DELETE payload is when you delete the IKE SA because some exchange over the IKE SA timed out (i.e. other end didn't respond). In that timeout case there is no point of sending DELETE payload, as most likely that will not reach the other end any better than the original exchange, thus it will also timeout. In this redirect case the client might just be slow, or it might be that the gateway where client was redirected to does not respond, and client does not delete the old IKE SA before it gets new one up and running. -- kivinen@iki.fi From kivinen@iki.fi Fri Mar 6 05:51:38 2009 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 EBD163A6A0B for ; Fri, 6 Mar 2009 05:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 AKvFNJSRgf86 for ; Fri, 6 Mar 2009 05:51:38 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id CFF283A69BA for ; Fri, 6 Mar 2009 05:51:37 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n26Dq1uv012859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2009 15:52:01 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n26Dq0ef003945; Fri, 6 Mar 2009 15:52:00 +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: <18865.10880.221267.329987@fireball.kivinen.iki.fi> Date: Fri, 6 Mar 2009 15:52:00 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EFC5@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EFC5@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min Cc: "ipsec@ietf.org" , "Pasi.Eronen@nokia.com" , "rfgraveman@gmail.com" , Vijay Devarapalli Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 06 Mar 2009 13:51:39 -0000 Yaron Sheffer writes: > I have a slight preference to keeping the protocol symmetric. But > even if we choose not to do that, I think Tero's text (quoted below) > leaves too much room for interpretation. Redirect is not really symmetric ever. If it would be used in symmetric way, then each end would simply create the connection using the address they want whenever they want. I.e. if server wanted to redirect client to somewhere else later, it would simply inform that new gateway to make connection to the client and close the local connection. That new gateway would then simply initiate new connection to the client and move traffic to there. The reason we cannot do that is that client-server connections are very often asymmetric, i.e. we are using EAP, or client is behind NAT or similar problems. > 7. Use of the Redirect Mechanism between IKEv2 Peers > > The Re-direct mechanism described in this document is mainly intended > for use in client-gateway scenarios. However, the mechanism can also > be used between any two IKEv2 peers, but this protocol is > asymmetric, meaning that only the responder can redirect initiator > to some other server. > --- > > The protocol supports using an Informational exchange for redirect > at any time during the SA lifetime, and this is inherently > symmetric. No, it does not make it symmetric. If the original initiator wants to use other local address when connecting, he will simply switch to that new address and initiate new connection. Original responder cannot do that, as most likely the connection using new address does not work because of NATs or because of asymmetric authentication type used (EAP). > And of course, following an IKE SA rekey, the > initiator/responder roles might change. If we go for the restricted > option, the new text should cover both of these issues. I should have used "original responder" and "original initiator". -- kivinen@iki.fi From yaronf@checkpoint.com Fri Mar 6 08:34:08 2009 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 730343A6A3B for ; Fri, 6 Mar 2009 08:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.322 X-Spam-Level: X-Spam-Status: No, score=-3.322 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, 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 1--vpL1mNeWs for ; Fri, 6 Mar 2009 08:34:07 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 354563A685C for ; Fri, 6 Mar 2009 08:34:06 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n26GYX16013194; Fri, 6 Mar 2009 18:34:33 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Fri, 6 Mar 2009 18:34:33 +0200 From: Yaron Sheffer To: Tero Kivinen Date: Fri, 6 Mar 2009 18:34:34 +0200 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 Thread-Index: AcmeYryA4pmyUFUBSTqbbuJmCOmyAgAFdrJA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EFF2@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EFC5@il-ex01.ad.checkpoint.com> <18865.10880.221267.329987@fireball.kivinen.iki.fi> In-Reply-To: <18865.10880.221267.329987@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: "ipsec@ietf.org" , "Pasi.Eronen@nokia.com" , "rfgraveman@gmail.com" , Vijay Devarapalli Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 06 Mar 2009 16:34:08 -0000 Hi Tero, We are thinking of different use cases. You are thinking VPN client - VPN server (and similar client/server cases).= I agree that client-side redirect is useless in this case. MOBIKE takes ca= re very well of the multihomed case (one address on WLAN, another on GPRS).= So I don't care if the current draft doesn't work for that case. I am thinking of symmetric IKE peers (gateways, or endpoints using transpor= t mode ESP; no EAP, rarely any NAT). Is there any reason why the current dr= aft cannot support this case in a symmetric manner? Thanks, Yaron > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Friday, March 06, 2009 15:52 > To: Yaron Sheffer > Cc: Vijay Devarapalli; Pasi.Eronen@nokia.com; ipsec@ietf.org; > rfgraveman@gmail.com > Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 >=20 > Yaron Sheffer writes: > > I have a slight preference to keeping the protocol symmetric. But > > even if we choose not to do that, I think Tero's text (quoted below) > > leaves too much room for interpretation. >=20 > Redirect is not really symmetric ever. If it would be used in > symmetric way, then each end would simply create the connection using > the address they want whenever they want. I.e. if server wanted to > redirect client to somewhere else later, it would simply inform that > new gateway to make connection to the client and close the local > connection. That new gateway would then simply initiate new connection > to the client and move traffic to there. >=20 > The reason we cannot do that is that client-server connections are > very often asymmetric, i.e. we are using EAP, or client is behind NAT > or similar problems. >=20 > > 7. Use of the Redirect Mechanism between IKEv2 Peers > > > > The Re-direct mechanism described in this document is mainly intende= d > > for use in client-gateway scenarios. However, the mechanism can als= o > > be used between any two IKEv2 peers, but this protocol is > > asymmetric, meaning that only the responder can redirect initiator > > to some other server. > > --- > > > > The protocol supports using an Informational exchange for redirect > > at any time during the SA lifetime, and this is inherently > > symmetric. >=20 > No, it does not make it symmetric. If the original initiator wants to > use other local address when connecting, he will simply switch to that > new address and initiate new connection. Original responder cannot do > that, as most likely the connection using new address does not work > because of NATs or because of asymmetric authentication type used > (EAP). >=20 > > And of course, following an IKE SA rekey, the > > initiator/responder roles might change. If we go for the restricted > > option, the new text should cover both of these issues. >=20 > I should have used "original responder" and "original initiator". > -- > kivinen@iki.fi >=20 > Scanned by Check Point Total Security Gateway. >=20 > Scanned by Check Point Total Security Gateway. From root@core3.amsl.com Fri Mar 6 11:30:02 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1B1B13A6CD3; Fri, 6 Mar 2009 11:30:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090306193002.1B1B13A6CD3@core3.amsl.com> Date: Fri, 6 Mar 2009 11:30:02 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-roadmap-01.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: Fri, 06 Mar 2009 19:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap Author(s) : S. Frankel, S. Krishnan Filename : draft-ietf-ipsecme-roadmap-01.txt Pages : 49 Date : 2009-03-06 Over the past few years, the number of RFCs that define and use IPsec and IKE has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic. This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes the previous IPsec Document Roadmap [RFC2411]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-roadmap-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-roadmap-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-06112953.I-D@ietf.org> --NextPart-- From vijay@wichorus.com Fri Mar 6 15:23:08 2009 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 B276E3A6924 for ; Fri, 6 Mar 2009 15:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 MgLh+1ZJUqce for ; Fri, 6 Mar 2009 15:23:08 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id B5BDC3A696E for ; Fri, 6 Mar 2009 15:23:07 -0800 (PST) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA05.westchester.pa.mail.comcast.net with comcast id Ps501b01t0ldTLk55zPfqd; Fri, 06 Mar 2009 23:23:39 +0000 Received: from [10.166.254.110] ([99.51.129.145]) by OMTA04.westchester.pa.mail.comcast.net with comcast id PzPJ1b00338Mh0K3QzPPxs; Fri, 06 Mar 2009 23:23:37 +0000 Message-ID: <49B1B065.9080703@wichorus.com> Date: Fri, 06 Mar 2009 15:23:17 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Tero Kivinen References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <18865.10345.214381.996149@fireball.kivinen.iki.fi> In-Reply-To: <18865.10345.214381.996149@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, rfgraveman@gmail.com, Vijay Devarapalli Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 06 Mar 2009 23:23:08 -0000 Tero Kivinen wrote: > Vijay Devarapalli writes: >> The draft currently requires the client to delete the SA once it >> receives the REDIRECT message from the gateway. I do not want the >> gateway to delete the SA right away. The gateway should allow the >> client to setup the necessary security associations with the new >> gateway before deleting the SA with the existing gateway, if that is >> what the client wants to do. The current text is to handle the case >> where for some reason the gateway does not receive the DELETE payload >> from the client. Note that this shouldn't happen normally. The gateway >> garbage collects the SA after a certain time period. I don't think the >> gateway needs to send a DELETE payload at this point. > > I disagree with that. If gateway decides to delete the IKE SA, it > needs to send DELETE payload in that case. The only case where you do > not send DELETE payload is when you delete the IKE SA because some > exchange over the IKE SA timed out (i.e. other end didn't respond). In > that timeout case there is no point of sending DELETE payload, as most > likely that will not reach the other end any better than the original > exchange, thus it will also timeout. > > In this redirect case the client might just be slow, or it might be > that the gateway where client was redirected to does not respond, and > client does not delete the old IKE SA before it gets new one up and > running. The timeout on the gateway can be quite large. The gateway should give sufficient time for the client to delete the SA. If the client does not for some reason, (note that the client is required to delete the SA), the SAs are just removed. The gateway has already sent a REDIRECT message to the client. Sending yet another INFORMATIONAL message with the DELETE payload after a certain time period, is just an overhead, IMHO. Vijay From yaronf@checkpoint.com Sun Mar 8 05:47:50 2009 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 C86683A6B8C for ; Sun, 8 Mar 2009 05:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[AWL=-0.246, 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 H3VgrWuY6U98 for ; Sun, 8 Mar 2009 05:47:49 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 09D3C3A67AC for ; Sun, 8 Mar 2009 05:47:49 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id EB5F82CC002; Sun, 8 Mar 2009 14:48:20 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A7BA42CC001; Sun, 8 Mar 2009 14:48:19 +0200 (IST) X-CheckPoint: {49B3BDF8-0-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n28CmI16005159; Sun, 8 Mar 2009 14:48:19 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sun, 8 Mar 2009 14:48:18 +0200 From: Yaron Sheffer To: Vijay Devarapalli , Tero Kivinen Date: Sun, 8 Mar 2009 14:48:17 +0200 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 Thread-Index: AcmespqINAYKjZ0nS/GohzJw6rnWJABOMeOA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F0B0@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <18865.10345.214381.996149@fireball.kivinen.iki.fi> <49B1B065.9080703@wichorus.com> In-Reply-To: <49B1B065.9080703@wichorus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0061_01C99FFC.EAC40660" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Vijay, "Pasi.Eronen@nokia.com" , Devarapalli , "rfgraveman@gmail.com" Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 08 Mar 2009 12:47:50 -0000 ------=_NextPart_000_0061_01C99FFC.EAC40660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Vijay, I'd rather be consistent with IKE, i.e. send an explicit DELETE. I suggest to change the -04 text: Once the client sends an acknowledgement to the gateway, it SHOULD delete the existing security associations with the old gateway by sending an Informational message with a DELETE payload. The gateway MAY also decide to delete the security associations without any signaling from the client. To: Once the client sends an acknowledgement to the gateway, it SHOULD delete the existing security associations with the old gateway by sending an Informational message with a DELETE payload. The gateway MAY also decide to delete the security associations without any signaling from the client, again by sending an Informational message with a DELETE payload. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Vijay Devarapalli > Sent: Saturday, March 07, 2009 1:23 > To: Tero Kivinen > Cc: ipsec@ietf.org; Pasi.Eronen@nokia.com; rfgraveman@gmail.com; Vijay > Devarapalli > Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 > > Tero Kivinen wrote: > > Vijay Devarapalli writes: > >> The draft currently requires the client to delete the SA once it > >> receives the REDIRECT message from the gateway. I do not want the > >> gateway to delete the SA right away. The gateway should allow the > >> client to setup the necessary security associations with the new > >> gateway before deleting the SA with the existing gateway, if that is > >> what the client wants to do. The current text is to handle the case > >> where for some reason the gateway does not receive the DELETE payload > >> from the client. Note that this shouldn't happen normally. The gateway > >> garbage collects the SA after a certain time period. I don't think the > >> gateway needs to send a DELETE payload at this point. > > > > I disagree with that. If gateway decides to delete the IKE SA, it > > needs to send DELETE payload in that case. The only case where you do > > not send DELETE payload is when you delete the IKE SA because some > > exchange over the IKE SA timed out (i.e. other end didn't respond). In > > that timeout case there is no point of sending DELETE payload, as most > > likely that will not reach the other end any better than the original > > exchange, thus it will also timeout. > > > > In this redirect case the client might just be slow, or it might be > > that the gateway where client was redirected to does not respond, and > > client does not delete the old IKE SA before it gets new one up and > > running. > > The timeout on the gateway can be quite large. The gateway should give > sufficient time for the client to delete the SA. If the client does not > for some reason, (note that the client is required to delete the SA), > the SAs are just removed. The gateway has already sent a REDIRECT > message to the client. Sending yet another INFORMATIONAL message with > the DELETE payload after a certain time period, is just an overhead, IMHO. > > Vijay > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0061_01C99FFC.EAC40660 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDMwODEyNDgxN1owIwYJKoZIhvcNAQkEMRYEFMbVI7yBZOYI G/t/ymvdpLy4ObamMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA LRRz1qLKlGcLjERzmFTqTzGR5HUoy4A6vxFDOZwHNibFNbKXqT4kc8C9OwKtunxCBUPhO2Ny3Ilh L/eT4cb06ypknCIhDOi2AtmlRQA5m+L+I0DfOgZy7LyQx79nrif4H2mGg7TyuQdnIESuyF/cumwZ ANfF8IJCmkUpsPpTLQIcHCFyq+9D1+ag55f6tigYW8dgzKneROzs9t83XP4V2906WEKrapWLAK5j HdEPlWG8U9oXEVKLkcmRzY6Xn8cfeG5kWTjZKEaSbONJuBk2UuoDrtcx0YoyPmzH5UVDY53vLKH7 Vu6uMMMMmr142GM91/KkoAvxLFIKC28d9Ky+VwAAAAAAAA== ------=_NextPart_000_0061_01C99FFC.EAC40660-- From raghup@cisco.com Mon Mar 9 03:08:45 2009 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 EAEF63A6BEE for ; Mon, 9 Mar 2009 03:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 p0Ib6oiyLhhy for ; Mon, 9 Mar 2009 03:08:45 -0700 (PDT) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 1892728C0D6 for ; Mon, 9 Mar 2009 03:08:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,328,1233532800"; d="scan'208,217";a="44816375" Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-1.cisco.com with ESMTP; 09 Mar 2009 10:09:15 +0000 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n29A9EGC015712 for ; Mon, 9 Mar 2009 15:39:14 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n29A9D8Y013057 for ; Mon, 9 Mar 2009 10:09:13 GMT Received: from XMB-BLR-419.apac.cisco.com ([64.104.140.154]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 15:39:14 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A09F.194268AB" Date: Mon, 9 Mar 2009 15:39:14 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Query on IKEv2 SA Thread-Index: Acmgnxlk0aMlePGUR5m4Lo5oZ4xzWQ== From: "Raghunandan P (raghup)" To: X-OriginalArrivalTime: 09 Mar 2009 10:09:14.0151 (UTC) FILETIME=[194D4B70:01C9A09F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4020; t=1236593355; x=1237457355; c=relaxed/simple; s=inddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raghup@cisco.com; z=From:=20=22Raghunandan=20P=20(raghup)=22=20 |Subject:=20Query=20on=20IKEv2=20SA |Sender:=20; bh=tMbM+TR5kNg4yt4ran/eoD+hiDqHpQK/m4GC2VNDOEw=; b=I6JcWQUxVAq6EIuzOuTtgdLdEvliNLV6z3r9mIOJ1OzZ43F5J2LZYq3BiT LXG1fEvLZez+lSCBqUSMlhjpR+drxwRLL31DmMnb/0elANrsFCCD87jUyWB2 8nfPryS1ZZ; Authentication-Results: ind-dkim-1; header.From=raghup@cisco.com; dkim=pass ( sig from cisco.com/inddkim1002 verified; ); Subject: [IPsec] Query on IKEv2 SA 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, 09 Mar 2009 10:08:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A09F.194268AB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I had a query related to the IKEv2 SA existance and the method used to delete it. =20 IKEv2 protocol supports continous channel mode, which implies that once we delete IKEv2 SA, all the IPSec SAs created using this IKEv2 SA also get deleted. However, if the last IPSec SA is deleted, the IKEv2 SA is not deleted. Is this understanding correct? =20 If the above is correct, what is the purpose of having this standalong IKEv2 SA? Since maintaining the IKEv2 SA consumes resources in the system, what is the advantage offered by having this standalong IKEv2 SA? =20 If the standalone IKEv2 is indeed brought up, when is this IKEv2 SA deleted and what is the method used to delete this IKEv2 SA? One example is a phase 2 proposal mismatch, in which case, we can still bring up the IKEv2 SA only. How is the IKEv2 SA deleted in this case and in any other general case? =20 I could not find much information on this in the draft and hence more clarity would help. =20 Thanks Raghu =20 =20 ------_=_NextPart_001_01C9A09F.194268AB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
I had = a query=20 related to the IKEv2 SA existance and the method used to delete=20 it.
 
IKEv2 = protocol=20 supports continous channel mode, which implies that once we delete IKEv2 = SA, all=20 the IPSec SAs created using this IKEv2 SA also get deleted. = However, if the=20 last IPSec SA is deleted, the IKEv2 SA is not deleted. Is this = understanding=20 correct?
 
If the = above is=20 correct, what is the purpose of having this standalong IKEv2 SA? Since=20 maintaining the IKEv2 SA consumes resources in the system, what is the = advantage=20 offered by having this standalong IKEv2 SA?
 
If the = standalone=20 IKEv2 is indeed brought up, when is this IKEv2 SA deleted and what is = the method=20 used to delete this IKEv2 SA? One example is a phase 2 proposal = mismatch, in=20 which case, we can still bring up the IKEv2 SA only. How is the IKEv2 SA = deleted=20 in this case and in any other general case?
 
I = could not find=20 much information on this in the draft and hence more clarity would=20 help.
 
Thanks
Raghu
 
 
------_=_NextPart_001_01C9A09F.194268AB-- From ynir@checkpoint.com Mon Mar 9 04:01:21 2009 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 3900328C11E for ; Mon, 9 Mar 2009 04:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 PFBJRKxOYtun for ; Mon, 9 Mar 2009 04:01:20 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 837213A6B7A for ; Mon, 9 Mar 2009 04:01:19 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6651C2CC004; Mon, 9 Mar 2009 13:01:52 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 8A2B22CC002; Mon, 9 Mar 2009 13:01:50 +0200 (IST) X-CheckPoint: {49B4F672-0-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n29B1n16009262; Mon, 9 Mar 2009 13:01:50 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 9 Mar 2009 13:01:49 +0200 From: Yoav Nir To: "Raghunandan P (raghup)" , "ipsec@ietf.org" Date: Mon, 9 Mar 2009 13:02:22 +0200 Thread-Topic: Query on IKEv2 SA Thread-Index: Acmgnxlk0aMlePGUR5m4Lo5oZ4xzWQABoEVg Message-ID: <9FB7C7CE79B84449B52622B506C78036133299EF3A@il-ex01.ad.checkpoint.com> 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_9FB7C7CE79B84449B52622B506C78036133299EF3Ailex01adcheck_" MIME-Version: 1.0 Subject: Re: [IPsec] Query on IKEv2 SA 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, 09 Mar 2009 11:01:21 -0000 --_000_9FB7C7CE79B84449B52622B506C78036133299EF3Ailex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Raghu. You are correct. It is not mandatory to delete an IKE SA without child SAs. The draft does not specify the complete behavior of all products that imple= ment it. It describes a language (IKE) by which two implementations may "co= nverse" If is perfectly valid to create an implementation where having a "child-les= s" IKE SA is not acceptable. Such an implementation would delete the IKE SA= if no child SAs are left. It is also perfectly valid not to do so. For an example, think of the remote access case using EAP for user password= s (or using certificate stored in MS CAPI or Apple Keychain, where you need= a password to unlock the cert). Setting up an IKE SA is not only computat= ionally intensive (Diffie-Hellman), but also intrusive as it requires user = interaction. Suppose we had a child SA used to reach the mail server. Sinc= e the mail client only connects once every 10 minutes, the child SA times o= ut and is deleted without a rekey. If either the client or the gateway now= delete the IKE SA, then we will again require user interaction to set up t= he new IKE SA. That is not the user experience we want. Better to keep th= e IKE SA and have the child SA set up automatically when the need arises. Hope this helps Yoav ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of R= aghunandan P (raghup) Sent: Monday, March 09, 2009 12:09 PM To: ipsec@ietf.org Subject: [IPsec] Query on IKEv2 SA Hi, I had a query related to the IKEv2 SA existance and the method used to dele= te it. IKEv2 protocol supports continous channel mode, which implies that once we = delete IKEv2 SA, all the IPSec SAs created using this IKEv2 SA also get del= eted. However, if the last IPSec SA is deleted, the IKEv2 SA is not deleted= . Is this understanding correct? If the above is correct, what is the purpose of having this standalong IKEv= 2 SA? Since maintaining the IKEv2 SA consumes resources in the system, what= is the advantage offered by having this standalong IKEv2 SA? If the standalone IKEv2 is indeed brought up, when is this IKEv2 SA deleted= and what is the method used to delete this IKEv2 SA? One example is a phas= e 2 proposal mismatch, in which case, we can still bring up the IKEv2 SA on= ly. How is the IKEv2 SA deleted in this case and in any other general case? I could not find much information on this in the draft and hence more clari= ty would help. Thanks Raghu =0D=0A Email secured by Check Point=0D=0A --_000_9FB7C7CE79B84449B52622B506C78036133299EF3Ailex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Raghu.
 
You are correct. It is not mandatory to delete an IKE= SA=20 without child SAs.
 
The draft does not specify the complete behavior of a= ll=20 products that implement it. It describes a language (IKE) by which two=20 implementations may "converse"
 
If is perfectly valid to create an implementation whe= re having=20 a "child-less" IKE SA is not acceptable. Such an implementation would delet= e the=20 IKE SA if no child SAs are left. It is also perfectly valid not to do=20 so.
 
For an example, think of the remote access case using= EAP for=20 user passwords (or using certificate stored in MS CAPI or Apple Keychain, w= here=20 you need a password to unlock the cert).  Setting up an IKE SA is not = only=20 computationally intensive (Diffie-Hellman), but also intrusive as it requir= es=20 user interaction.  Suppose we had a child SA used to reach the mail se= rver.=20 Since the mail client only connects once every 10 minutes, the child SA tim= es=20 out and is deleted without a rekey.  If either the client or the gatew= ay=20 now delete the IKE SA, then we will again require user interaction to set u= p the=20 new IKE SA.  That is not the user experience we want.  Better to = keep=20 the IKE SA and have the child SA set up automatically when the need=20 arises.
 
Hope this helps
 
Yoav

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Raghunandan P=20 (raghup)
Sent: Monday, March 09, 2009 12:09 PM
To:=20 ipsec@ietf.org
Subject: [IPsec] Query on IKEv2=20 SA

Hi,
I had a= query=20 related to the IKEv2 SA existance and the method used to delete=20 it.
 
IKEv2 p= rotocol=20 supports continous channel mode, which implies that once we delete IKEv2 = SA,=20 all the IPSec SAs created using this IKEv2 SA also get deleted. Howe= ver,=20 if the last IPSec SA is deleted, the IKEv2 SA is not deleted. Is this=20 understanding correct?
 
If the = above is=20 correct, what is the purpose of having this standalong IKEv2 SA? Since=20 maintaining the IKEv2 SA consumes resources in the system, what is the=20 advantage offered by having this standalong IKEv2 SA?
 
If the = standalone=20 IKEv2 is indeed brought up, when is this IKEv2 SA deleted and what is the= =20 method used to delete this IKEv2 SA? One example is a phase 2 proposal=20 mismatch, in which case, we can still bring up the IKEv2 SA only. How is = the=20 IKEv2 SA deleted in this case and in any other general=20 case?
 
I could= not find=20 much information on this in the draft and hence more clarity would=20 help.
 
Thanks
Raghu
 
 

= =0D=0A
Email secured by Check Point=0D=0A

= = --_000_9FB7C7CE79B84449B52622B506C78036133299EF3Ailex01adcheck_-- From kivinen@iki.fi Mon Mar 9 06:10:15 2009 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 517283A6C9D for ; Mon, 9 Mar 2009 06:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 wCqOD8dJ2ucA for ; Mon, 9 Mar 2009 06:10:14 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 0E3AE3A6C97 for ; Mon, 9 Mar 2009 06:10:13 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n29DAdlC011663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 15:10:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n29DAcCY012023; Mon, 9 Mar 2009 15:10:38 +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: <18869.5454.101452.948354@fireball.kivinen.iki.fi> Date: Mon, 9 Mar 2009 15:10:38 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EFF2@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EFC5@il-ex01.ad.checkpoint.com> <18865.10880.221267.329987@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EFF2@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 8 min Cc: "ipsec@ietf.org" , "Pasi.Eronen@nokia.com" , "rfgraveman@gmail.com" , Vijay Devarapalli Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 09 Mar 2009 13:10:15 -0000 Yaron Sheffer writes: > I am thinking of symmetric IKE peers (gateways, or endpoints using > transport mode ESP; no EAP, rarely any NAT). Is there any reason why > the current draft cannot support this case in a symmetric manner? Why do you need any protocol for that. Why does not normal IKEv2 be enough for that. I.e. if node A wants the node B to move to use some other location, it can simply connect to node B using that new location, and remove the old IKE SA. I.e. if scenario is really symmetric, there is no need to have any IKEv2 redirect protocol at all, everything can be done by the node by directly connecting using new location. It is quite hard to explain this thing as I have no idea what kind of scenario you are talking about. Can you give real example, what the nodes are and why do they want to redirect other end. MOBIKE is not restricted to the VPN client <-> VPN server situation, but is limited that node must stay same. I.e. it is moving between multiple addresses of node A and moving between multiple address of node B. It cannot ask node B to move from node A to node C. But if node A wants node B to use node C instead of node A, it can simply inform node C to make connection to B and delete its own IKE SA. It can also do this by just changing the back end routing or similar, so that return packets go to node C instead of node A and then node C will initiate connection to node B immediately when first packet arrives (if the situation is really symmetric). If we are talking about client and server situations where server wants to redirect client to some other server, then situation is no longer symmetric. -- kivinen@iki.fi From kivinen@iki.fi Mon Mar 9 06:24:15 2009 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 98F9628C20B for ; Mon, 9 Mar 2009 06:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 cOarnQmOmSfF for ; Mon, 9 Mar 2009 06:24:11 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E18D028C201 for ; Mon, 9 Mar 2009 06:24:10 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n29DOHeQ011495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 15:24:17 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n29DOH9H011799; Mon, 9 Mar 2009 15:24:17 +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: <18869.6273.712435.201688@fireball.kivinen.iki.fi> Date: Mon, 9 Mar 2009 15:24:17 +0200 From: Tero Kivinen To: "Raghunandan P (raghup)" In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 12 min Cc: ipsec@ietf.org Subject: [IPsec] Query on IKEv2 SA 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, 09 Mar 2009 13:24:15 -0000 Raghunandan P (raghup) writes: > IKEv2 protocol supports continous channel mode, which implies that once > we delete IKEv2 SA, all the IPSec SAs created using this IKEv2 SA also > get deleted. However, if the last IPSec SA is deleted, the IKEv2 SA is > not deleted. Is this understanding correct? Yes, that is correct. You can have IKE SA without any Child/IPsec SAs. > If the above is correct, what is the purpose of having this standalong > IKEv2 SA? Since maintaining the IKEv2 SA consumes resources in the > system, what is the advantage offered by having this standalong IKEv2 > SA? Lets say you have situation where you create new Child/IPsec SA for each TCP connection. With for example web traffic those TCP connections are quite short lived, and it would be very expensive to create new IKE SA for each of them, so you want to create them using same IKE SA. When the last TCP connection goes away (and user is reading the web page), the IKE SA will still be kept there, and then when user clicks some link to fetch more stuff from the server, new TCP connections are created, and those can be created using the already existing IKE SA. So in some scenarios it is advantageous to keep the IKEv2 SA up even after the last Child/IPsec SA disappears. In some scenarios it might be useful to put some kind of idle timer there, and delete that IKEv2 SA if it stays there for too long (for example more than 10-30 minutes). > If the standalone IKEv2 is indeed brought up, when is this IKEv2 SA > deleted and what is the method used to delete this IKEv2 SA? One example > is a phase 2 proposal mismatch, in which case, we can still bring up the > IKEv2 SA only. How is the IKEv2 SA deleted in this case and in any other > general case? IKEv2 SAs are only deleted by two ways: 1) Explicit INFORMATIONAL exchange having delete payload in request packet (with Protocol ID 1 for IKE_SA, and empty SPI), and other ends response packet (without delete payload, so this response is usually just empty packet (i.e only encrypted payload but nothing in there). 2) By timeout, i.e. if other end does not send response to the request that has been "retransmitted at least a dozen times over a period of at least several minutes before giving up on an SA". In that case the IKE SA is simply remoeved from memory, without further communcations to the other end. Note, that case 1 applies also to the old IKE SA after IKE SA rekey, i.e. even that will be deleted by sending delete payload in INFORMATIONAL exchange. > I could not find much information on this in the draft and hence more > clarity would help. Case 1 is explained in section 3.11 of RFC 4306 and section 5.8 of RFC4718. Case 2 is explained in section 2.4 of RFC 4306. -- kivinen@iki.fi From yaronf@checkpoint.com Mon Mar 9 09:30:58 2009 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 01AAF3A6C9F for ; Mon, 9 Mar 2009 09:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.825 X-Spam-Level: X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[AWL=-0.227, 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 5HKNtF2MRKow for ; Mon, 9 Mar 2009 09:30:54 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 045823A6C86 for ; Mon, 9 Mar 2009 09:30:54 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 1F0702CC002; Mon, 9 Mar 2009 18:31:27 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D64702CC001 for ; Mon, 9 Mar 2009 18:31:25 +0200 (IST) X-CheckPoint: {49B543AD-0-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n29GVP16025566 for ; Mon, 9 Mar 2009 18:31:25 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 9 Mar 2009 18:31:24 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Mon, 9 Mar 2009 18:31:23 +0200 Thread-Topic: IKEv2-bis open issues - an emotional reminder Thread-Index: Acmg1HwbsQ6LIgdUSlGvpZbf0J2anw== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F26C@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_005D_01C9A0E5.3FA8C5B0" MIME-Version: 1.0 Subject: [IPsec] IKEv2-bis open issues - an emotional reminder 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, 09 Mar 2009 16:30:58 -0000 ------=_NextPart_000_005D_01C9A0E5.3FA8C5B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_005E_01C9A0E5.3FA8C5B0" ------=_NextPart_001_005E_01C9A0E5.3FA8C5B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi everyone, Last Tuesday I posted another batch of open issues to the list. Unfortunately there's been almost no response. We as a group can certainly do better than that! I'd like to encourage y'all to please take another look at your inbox and help us close these issues! Thanks, Yaron ------=_NextPart_001_005E_01C9A0E5.3FA8C5B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everyone,

 

Last Tuesday I posted another batch of open issues to = the list. Unfortunately there’s been almost no response. We as a group = can certainly do better than that! I’d like to encourage y’all = to please take another look at your inbox and help us close these = issues!

 

Thanks,

         =    Yaron

------=_NextPart_001_005E_01C9A0E5.3FA8C5B0-- ------=_NextPart_000_005D_01C9A0E5.3FA8C5B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDMwOTE2MzEyM1owIwYJKoZIhvcNAQkEMRYEFHUTSxkF9bKy JYvRAa+wKEgdLqW9MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA JAArR5LzehAAcdbe6nOjLz5Ds1xAxEsP/65krHAE+o7NoePmqvbbiK0QuFS/Ow2PtS1Nr+gfK+BA gkh3xnGE1RR/7YiIfqUUsXFEsvb/7ISxP7CFxq2WBuR25SFkLVv1zHwVKKfMxcrgapPcFocEow7p eyCIG+L5p0MEtJvNvRJtGLBL+zcHmf9xHAF03zQf0c2cyTMyK2ZJaAi8IZPQ3s7HWpAQf2fYol/2 3D2JDaKNIYIBApwq5D/r5Z54ORpdSuEFqrApesyjyEYh/ZnJJLCwCR4Vsf0LGb2hvDJZM/t4+HL1 6Z5pPCcuDdZwVfvMhLpl30n2QQhqP6ecAqvW2QAAAAAAAA== ------=_NextPart_000_005D_01C9A0E5.3FA8C5B0-- From welterk@us.ibm.com Mon Mar 9 11:06:59 2009 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 8A1133A6358 for ; Mon, 9 Mar 2009 11:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 iq3UaSUlV1ZQ for ; Mon, 9 Mar 2009 11:06:58 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 6ED0A3A6CCB for ; Mon, 9 Mar 2009 11:06:55 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n29I68s8019816 for ; Mon, 9 Mar 2009 12:06:08 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n29I7Rww161622 for ; Mon, 9 Mar 2009 12:07:28 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n29I7R2c025827 for ; Mon, 9 Mar 2009 12:07:27 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n29I7ROI025821 for ; Mon, 9 Mar 2009 12:07:27 -0600 To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Keith Welter X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 03/09/2009 11:07:29 AM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 03/09/2009 11:07:29 AM, Serialize complete at 03/09/2009 11:07:29 AM, S/MIME Sign failed at 03/09/2009 11:07:29 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 03/09/2009 12:07:27, Serialize complete at 03/09/2009 12:07:27 Message-ID: Date: Mon, 9 Mar 2009 11:07:26 -0700 Content-Type: multipart/alternative; boundary="=_alternative 0063900688257574_=" Subject: [IPsec] Questions about RFC 4945 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, 09 Mar 2009 18:06:59 -0000 This is a multipart message in MIME format. --=_alternative 0063900688257574_= Content-Type: text/plain; charset="US-ASCII" First, is this the right mailing on which to post questions about RFC 4945? Second, should RFC 4945 section 4 (Use of Certificates in RFC 4301 and IKEv2) be considered a supplement to section 3 (Use of Certificates in RFC 2401 and IKEv1/ISAKMP) or should section 3 and section 4 be considered to be completely independent? For example, I'm wondering if the IP validation check described in section 3.1.1 should apply to IKEv2 in addition to IKEv1 or only to IKEv1. Keith Welter IBM Enterprise Networking Solutions 1-415-545-2694 (T/L: 473-2694) --=_alternative 0063900688257574_= Content-Type: text/html; charset="US-ASCII"
First, is this the right mailing on which to post questions about RFC 4945?

Second, should RFC 4945 section 4 (Use of Certificates in RFC 4301 and IKEv2) be considered a supplement to section 3 (Use of Certificates in RFC 2401 and IKEv1/ISAKMP) or should section 3 and section 4 be considered to be completely independent?  For example, I'm wondering if the IP validation check described in section 3.1.1 should apply to IKEv2 in addition to IKEv1 or only to IKEv1.

Keith Welter
IBM Enterprise Networking Solutions
1-415-545-2694 (T/L: 473-2694)
 --=_alternative 0063900688257574_=-- From root@core3.amsl.com Mon Mar 9 11:45:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E3E2B3A6BC6; Mon, 9 Mar 2009 11:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309184501.E3E2B3A6BC6@core3.amsl.com> Date: Mon, 9 Mar 2009 11:45:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-01.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: Mon, 09 Mar 2009 18:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Wrapped ESP for Traffic Visibility Author(s) : K. Grewal, G. Montenegro Filename : draft-ietf-ipsecme-traffic-visibility-01.txt Pages : 9 Date : 2009-03-09 This document describes an ESP encapsulation for IPsec, allowing intermediate devices to ascertain if ESP-NULL is being employed and hence inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec standard, there is no way to differentiate between ESP encryption and ESP NULL encryption by simply examining a packet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-traffic-visibility-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09114334.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Mar 9 13:00:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A98163A684B; Mon, 9 Mar 2009 13:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309200001.A98163A684B@core3.amsl.com> Date: Mon, 9 Mar 2009 13:00:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-resumption-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: Mon, 09 Mar 2009 20:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IKEv2 Session Resumption Author(s) : Y. Sheffer, et al. Filename : draft-ietf-ipsecme-ikev2-resumption-02.txt Pages : 22 Date : 2009-03-09 The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round-trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency. To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. In order to avoid the need to re-run the key exchange protocol from scratch it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. A client can reconnect to a gateway from which it was disconnected. The proposed approach requires passing opaque data from the IKEv2 responder to the IKEv2 initiator, which is later made available to the IKEv2 responder for re-authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but recommendations are provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-resumption-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09124602.I-D@ietf.org> --NextPart-- From paul.hoffman@vpnc.org Mon Mar 9 14:12:26 2009 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 B58A23A6BC2 for ; Mon, 9 Mar 2009 14:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 SQVWnqEYv8YD for ; Mon, 9 Mar 2009 14:12:26 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8802E3A69ED for ; Mon, 9 Mar 2009 14:12:25 -0700 (PDT) Received: from [165.227.249.202] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n29LCu3I081547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 14:12:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 9 Mar 2009 14:12:55 -0700 To: Keith Welter , ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Questions about RFC 4945 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, 09 Mar 2009 21:12:26 -0000 At 11:07 AM -0700 3/9/09, Keith Welter wrote: >First, is this the right mailing on which to post questions about RFC 4945? > >Second, should RFC 4945 section 4 (Use of Certificates in RFC 4301 and IKEv2) be considered a supplement to section 3 (Use of Certificates in RFC 2401 and IKEv1/ISAKMP) or should section 3 and section 4 be considered to be completely independent? Completely independent. --Paul Hoffman, Director --VPN Consortium From vijay@wichorus.com Mon Mar 9 14:24:03 2009 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 DDAE23A6884 for ; Mon, 9 Mar 2009 14:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 O23mnaqHvln8 for ; Mon, 9 Mar 2009 14:24:03 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 124F73A6CBA for ; Mon, 9 Mar 2009 14:24:01 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA01.westchester.pa.mail.comcast.net with comcast id R6ge1b0330xGWP8519Qdnu; Mon, 09 Mar 2009 21:24:37 +0000 Received: from [10.166.254.110] ([99.51.129.145]) by OMTA12.westchester.pa.mail.comcast.net with comcast id R9QB1b00Q38Mh0K3Y9QJfv; Mon, 09 Mar 2009 21:24:35 +0000 Message-ID: <49B5970C.8080602@wichorus.com> Date: Mon, 09 Mar 2009 14:24:12 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Yaron Sheffer References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <18865.10345.214381.996149@fireball.kivinen.iki.fi> <49B1B065.9080703@wichorus.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F0B0@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F0B0@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , Vijay Devarapalli , "Pasi.Eronen@nokia.com" , "rfgraveman@gmail.com" , Tero Kivinen Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 09 Mar 2009 21:24:04 -0000 Yaron Sheffer wrote: > Hi Vijay, > > I'd rather be consistent with IKE, i.e. send an explicit DELETE. Ok, I made this change, since there seems to be consensus for an explicit message when the gateway decides to remove the SA. Vijay > > I suggest to change the -04 text: > > Once the client sends an acknowledgement to the gateway, it SHOULD delete > the existing security associations with the old gateway by sending an > Informational message with a DELETE payload. The gateway MAY also decide to > delete the security associations without any signaling from the client. > > To: > > Once the client sends an acknowledgement to the gateway, it SHOULD delete > the existing security associations with the old gateway by sending an > Informational message with a DELETE payload. The gateway MAY also decide to > delete the security associations without any signaling from the client, > again by sending an Informational message with a DELETE payload. > > Thanks, > Yaron > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >> Vijay Devarapalli >> Sent: Saturday, March 07, 2009 1:23 >> To: Tero Kivinen >> Cc: ipsec@ietf.org; Pasi.Eronen@nokia.com; rfgraveman@gmail.com; Vijay >> Devarapalli >> Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 >> >> Tero Kivinen wrote: >>> Vijay Devarapalli writes: >>>> The draft currently requires the client to delete the SA once it >>>> receives the REDIRECT message from the gateway. I do not want the >>>> gateway to delete the SA right away. The gateway should allow the >>>> client to setup the necessary security associations with the new >>>> gateway before deleting the SA with the existing gateway, if that is >>>> what the client wants to do. The current text is to handle the case >>>> where for some reason the gateway does not receive the DELETE payload >>>> from the client. Note that this shouldn't happen normally. The gateway >>>> garbage collects the SA after a certain time period. I don't think the >>>> gateway needs to send a DELETE payload at this point. >>> I disagree with that. If gateway decides to delete the IKE SA, it >>> needs to send DELETE payload in that case. The only case where you do >>> not send DELETE payload is when you delete the IKE SA because some >>> exchange over the IKE SA timed out (i.e. other end didn't respond). In >>> that timeout case there is no point of sending DELETE payload, as most >>> likely that will not reach the other end any better than the original >>> exchange, thus it will also timeout. >>> >>> In this redirect case the client might just be slow, or it might be >>> that the gateway where client was redirected to does not respond, and >>> client does not delete the old IKE SA before it gets new one up and >>> running. >> The timeout on the gateway can be quite large. The gateway should give >> sufficient time for the client to delete the SA. If the client does not >> for some reason, (note that the client is required to delete the SA), >> the SAs are just removed. The gateway has already sent a REDIRECT >> message to the client. Sending yet another INFORMATIONAL message with >> the DELETE payload after a certain time period, is just an overhead, IMHO. >> >> Vijay >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. >> >> Scanned by Check Point Total Security Gateway. From vijay@wichorus.com Mon Mar 9 14:56:58 2009 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 443293A67F6 for ; Mon, 9 Mar 2009 14:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=-0.768, BAYES_00=-2.599, J_BACKHAIR_23=1, J_CHICKENPOX_23=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 M1wroCYUCYqd for ; Mon, 9 Mar 2009 14:56:57 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 094023A676A for ; Mon, 9 Mar 2009 14:56:56 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Mar 2009 17:57:30 -0400 Message-ID: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 Thread-Index: AcmQG11xz3Y00zEpSza195DYpuB4qgLVe3mQAWVyzAA= References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> From: "Vijay Devarapalli" To: Cc: ipsec@ietf.org, Jari Arkko , kent@bbn.com, kivinen@iki.fi Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 09 Mar 2009 21:56:58 -0000 Hi Pasi, I spent about three days thinking about this, but still couldn't conclude on anything. I am cc'ing Jari, since I thought he would interested in this topic and have some comments. As you observed, Mobile IPv6 does allows the mobile node to discover a Home Agent dynamically (See RFC 5026, RFC 4877 and draft-ietf-mip6-bootstrapping-integrated-dhc) and then create the corresponding PAD and SPD entries. We obviously do not convey what sort of authentication mechanism should be used with the gateway. It is assumed that the mobile node knows which authentication mechanism to use (based on the deployment) and store this information in the newly created PAD entry.=20 The use of DNS and DHCPv6 is allowed for discovering a home agent's address/FQDN. The discovery mechanisms based on DNS and DHCPv6 can be secured, but the secure form of these mechanisms might not be used always. So it is possible that you do end up with an insecure discovery mechanism creating new PAD and SPD entries on the mobile node. I never considered this a big deal, since the mobile node does authenticate the newly discovered home agent anyway. I also think the policy on the mobile node should be such that this discovery of a home agent should not modify existing PAD/SPD entries created using manual configuration, or some other configuration that results in persistent config state on the mobile node. I don't agree with the restriction that the original gateway and the new gateway should have the same IDr. That is too restrictive. For example, it should be possible for gw1 to redirect the client to gw2, with the two gateways having two distinct FQDNs. It is okay with me to recommend similar authentication mechanisms for the original and new gateways. But I would prefer not use a 'MUST' here. There could be scenarios where a different gateway means a different authentication mechanism. We should of course add some text in the security considerations section warning about REDIRECTs resulting in lower security with the new gateway.=20 Note that gateway-initiated redirect (section 5) is protected by the IKEv2 SA. It is not the same as the REDIRECT message that the client receives in the IKE_SA_INIT response. So we can't say that all REDIRECT messages are insecure.=20 I will not be able to resolve this in the version I am going to be submitting in the next couple of hours. I hope we can resolve this in the next few days. I will post another temporary version of the draft once we conclude on this issue. Regards, Vijay > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Pasi.Eronen@nokia.com > Sent: Monday, March 02, 2009 12:04 PM > To: ipsec@ietf.org > Subject: Re: [IPsec] WG Last Call:=20 > draft-ietf-ipsecme-ikev2-redirect-04 >=20 > >=20 > I have one somewhat substantial concern with the document: it needs to > be much clearer about what information is updated by the received > REDIRECT messages, and what is not. >=20 > While selecting the right peer when a new ESP/AH SA needs to be > created is not specified in RFC 4301 (see RFC 4555 Appendix A.2 for > some discussion), PAD definitely is in scope, and redirect could > interact with PAD in multiple ways. >=20 > For example, suppose the client decides that the right peer for the > ESP/AH SA is gw1.example.com. If after doing a DNS lookup and > contacting gw1.example.com it receives IDr/CERT payloads for > gw2.foobar.example, the client would report error and abort (at least > unless "the right peer for the SA" is actually a set of possible > peers, and gw2 happens to be in that set). >=20 > Now, suppose contacting gw1.example.com results in REDIRECT to > gw2.foobar.example (GW Identity Type=3DFQDN). When the client contacts > gw2, and receives IDr/CERT for gw2.foobar.example, does it accept it? >=20 > One possible answer would be that REDIRECT is interpreted just as data > received from DNS, so all the gateways (redirecting among each other) > would send same IDr value. >=20 > Another possible answer would be that if gw2.foobar.example is already > in client's local "set of right peers for this SA", then it would be > accepted (and the client would have accepted IDr/CERT with > gw2.foobar.example also in the beginning, before it got the redirect), > otherwise not. (And the client will also accept IDr/CERT > gw1.example.com even after the redirect, when contacting gw2 ---that > would be the sensible behavior if the redirect was with GW Identity > Type=3DIPv4/6.) >=20 > (Other answers than these two might be possible, too -- I have > not explored this in detail.) >=20 > Now, it's quite obvious the intent was to do redirect securely, but we > need to spell out what the correct behavior is: do all the gateways > have a single identity (IDr), or do they have distinct PAD entries? >=20 > (In the latter case, IKE_SA creation (with or without redirects) > succeeds only if the IDr has an entry in the PAD, and the peer is > successfully authenticated as required by the PAD. If the client > accepts IDr/CERT gw2.foobar.example, it would have also accepted it in > the first place (when trying to contact the IP address found by doing > DNS lookup for gw1.example.com, before it got any redirects). However, > in general there's no guarantee that the CHILD_SA authorization data > for the PAD entries "gw1.example.com" and "gw2.foobar.example" is > exactly the same, so although setting up the IKE_SA succeeds, creating > CHILD_SA with the intended selectors might not -- so by sending a > redirect, the gateway really assumes that the client has identical > CHILD_SA authorization data for the target.) >=20 > The situation gets tricker when we consider Mobile IPv6, though, > because we're also updating some data outside IPsec. What exactly is > being updated by the received REDIRECT, and is this secure? Also, the > SPD entries in RFC 4877 contain the HA address -- are we updating SPD > entries based on unauthenticated REDIRECT? >=20 > It seems some of this problem is already present in current MIP6 > bootstrapping documents (if we e.g. discover Home Agent IPv6 address > by DNS query, somehow the SPD entries must get there, based on usually > unauthenticated DNS response), and it's possible we could refer to > that work. But "treat REDIRECT just as it would have come from DNS" > is not without security issues, since MN might not use DNS to get the > HA address (we could be overwriting manually configured data known > to be secure), the DNS reply could have been protected by DNSSEC, or=20 > the attacker might be on MN<->GW1 path (and can spoof redirects) but=20 > not on MN/DNS server paths (so can't spoof the DNS reply). From A.Hoenes@tr-sys.de Mon Mar 9 15:35:06 2009 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 3BB363A6A04 for ; Mon, 9 Mar 2009 15:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.708 X-Spam-Level: * X-Spam-Status: No, score=1.708 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, GB_I_LETTER=-2, HELO_EQ_DE=0.35, MANGLED_LIST=2.3, MIME_8BIT_HEADER=0.3] 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 X1Mjh9ax+IbS for ; Mon, 9 Mar 2009 15:35:01 -0700 (PDT) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 9A25628C0D8 for ; Mon, 9 Mar 2009 15:35:00 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA259628017; Mon, 9 Mar 2009 23:33:37 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id XAA06138; Mon, 9 Mar 2009 23:33:36 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200903092233.XAA06138@TR-Sys.de> To: draft-ietf-ipsecme-roadmap@tools.ietf.org, ipsec@ietf.org Date: Mon, 9 Mar 2009 23:33:35 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: [IPsec] Some thoughts on draft-ietf-ipsecme-roadmap[-01] 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, 09 Mar 2009 22:35:06 -0000 Below are a few thoughts that came to my mind studying draft-ietf-ipsecme-roadmap. Admittedly, this review has originally been done for the -00 draft, and new material in the recent -01 has only been skimmed over quickly, but I hope that these considerations will be useful anyway. (A) Section 2.1 There are some more clearly distinct categories of documents, some new for the current version of IPsec / IKEv2 : o documents extending the architecture (MSEC etc., some are mentioned in section 6/8) -- this also comprises BTNS; o documents specifying key management extensions / alternatives to IKEv2 (also overlap with MSEC and BTNS!); o documents expanding the set of Authentication methods for IKEv2, in particular EAP methods suitable for IKEv2; o documents specifiying / advising on the application of IPsec in specific contexts / for specific applications. Should Sect. 2.1/2.* be amended with such categories? Would these groupings provide guidelines for another (perferable?) grouping of parts of Sect. 6..8 ? (B) Use of alternate cryptographic building blocks: Documents for IPsec transforms based on SEED and GOST primitives are not mentioned in the document so far. For more details regarding Camellia, see below. Linear walk-through including nits ++++++++++++++++++++++++++++++++++ (1) Sect.1 Only very specific RFCs specify their publication *date* (perhaps wait 3 weeks to see such!), they regularly only give the *month* -- and so does this memo. So I suggests to s/date/month/ . (2) Sect. 2.2.1, 1st para (recurs in 2.3.1) "IPsec ... use _in_ other protocols." does not match the protocol layering and might therefore be considered confusing. I suggest "use _with_ other protocols." (3) Sect. 3.1 -- "headers" Hmmm -- ESP is not a "header" , it is an encapsulation (as the 'E' in the acronyme says), having a header and a trailer part and an embedded encrypted payload (unless NULL encryption is used). Suggestion: s/[extension] headers/payload [protection] protocols/ . (4) Sect. 3.1.1 (RFC 2401) : s/the the/the/ (SAD) : s/factilitate/facilitate/ ^ (5) Sect. 3.1.2 "[RFC4301] updates [RFC2401]," Hmmm -- RFC 4301 indeed replaced / succeeded / superseded / *Obsoleted* RFC 2401 ! Similar for 2402 --> 4302 and 2406 --> 4303 . (6) Sect. 3.5 (RFC 5406) : Text should be amended to indicate that this memo is related to "Old" IPsec only! (7) Sect. 4.1.2 (RFC 4306) : s/DOI.It/DOI. It/ (8) Sect. 4.2.2 (RFC 4806) : s/(e.g. firewall)/(e.g., in a firewall)/ (9) Sect. 5.2 1st para: s/integrity(protection/integrity protection/ ^ ^ (RFC 4312) Updates are in progress for the use of Camellia in IPsec ... (draft-kato-ipsec-camellia-modes, draft-kato-camellia-ctrccm) (10) Sect. 5.3 The Japanese Cryptographic community is also in the process of defining integrity transforms based on Camellia in place of AES, for all common cipher-based integrity protection transforms. (11) Sect. 5.4, 1st para The IPsec documents generally reserve the term 'algorithm' to cryptographic primitives, and denotes the higher-level buliding blocks specifically customized to IPsec / IKEv* as "crytographic transforms". Thus, s/algorithm/"transform"/g ?? (12) Sect. 5.4 The Camellia documents mentioned above also introduce Camellia-CCM; another work-in-progress, draft-kato-ipsec-camellia-gcm, adds Camellia-GCM; both documents should perhaps be listed as well. (13) Sect. 5.5 The Camellia document set also is going to define Camellia-based PRFs for IKEv2. Should these be listed as well? (14) Sect. 5.6, 1st para -- "inifinite number" Combining transforms from finite sets of IANA registered algorithms and their finite variety of applicable parameter values, thank God, only yields a *finite* set of working combinations. "Infinite" should not be used thoughtlessly! (A similar issue recurs in Sect. 6, 1st para) (15) Sect. 5.7 -- headline IMHO, "Diffie-Hellman Algorithms" is perhaps too narrow. Why not use the more 'functional' and precise term, "Key Agreement Algorithms" ? (16) Sect. 7.6 (16a) headline The acronyms of DNS resource record types are written in all uppercase letters; so sorry, s/IPsecKEY/IPSECKEY/ ! ;-) (16b) body s/material in DNS/material in the DNS/ (17) References s/[RFC 5410]/[RFC5410]/ ^ Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From root@core3.amsl.com Mon Mar 9 16:30:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 80E803A69F4; Mon, 9 Mar 2009 16:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309233001.80E803A69F4@core3.amsl.com> Date: Mon, 9 Mar 2009 16:30:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-05.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: Mon, 09 Mar 2009 23:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Redirect Mechanism for IKEv2 Author(s) : V. Devarapalli, K. Weniger Filename : draft-ietf-ipsecme-ikev2-redirect-05.txt Pages : 12 Date : 2009-03-09 IKEv2 is a protocol for setting up VPN tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. Currently there is no standard mechanism specified that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway. This document proposes a redirect mechanism for IKEv2. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-redirect-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-redirect-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09161553.I-D@ietf.org> --NextPart-- From Pasi.Eronen@nokia.com Tue Mar 10 05:39:06 2009 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 DBCB73A6993 for ; Tue, 10 Mar 2009 05:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 he3LHHSrdh7l for ; Tue, 10 Mar 2009 05:39:06 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 0EB7C3A680E for ; Tue, 10 Mar 2009 05:39:05 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2ACd8Eh001891; Tue, 10 Mar 2009 07:39:38 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Mar 2009 14:39:32 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Mar 2009 14:39:27 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 10 Mar 2009 13:39:26 +0100 From: To: , Date: Tue, 10 Mar 2009 13:39:25 +0100 Thread-Topic: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04) Thread-Index: Acmd9hDE4gGkRQvNSv2BR/IZuNQF2ADhkr0g Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F1E98BFE@NOK-EUMSG-01.mgdnok.nokia.com> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 10 Mar 2009 12:39:27.0654 (UTC) FILETIME=[402E7460:01C9A17D] X-Nokia-AV: Clean Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04) 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, 10 Mar 2009 12:39:06 -0000 VmlqYXkgRGV2YXJhcGFsbGkgd3JvdGU6DQo+IA0KPiBIZWxsbywNCj4gDQo+IFRoZXJlIGF0IGxl YXN0IHRocmVlIHBlb3BsZSB3aG8gdGhpbmsgdGhhdCB0aGUgSUtFX0FVVEggcmVzcG9uc2UNCj4g bWVzc2FnZSBzaG91bGQgaXRzZWxmIGNvbnRhaW4gdGhlIFJFRElSRUNUIHBheWxvYWQuIEkgd2Vu dCB0aHJvdWdoDQo+IHRoZSBlbWFpbCBleGNoYW5nZSBiZXR3ZWVuIEZhbiBhbmQgVGVyby4gIFRo ZXJlIHdhcyBubyBuZXcNCj4gaW5mb3JtYXRpb24gdGhhdCBjYW1lIG91dCBvZiB0aGF0IGRpc2N1 c3Npb24gZm9yIG1lIHRvIG1ha2UgdGhpcw0KPiBjaGFuZ2UgaW4gdGhlIGRyYWZ0Lg0KPiANCj4g RG9lcyBhbnkgb25lIGVsc2UgaGF2ZSBhbiBvcGluaW9uPw0KDQpJIHRoaW5rIGluY2x1ZGluZyBS RURJUkVDVCBpbiB0aGUgZmluYWwgSUtFX0FVVEggcmVzcG9uc2Ugd291bGQgYmUNCnNpbXBsZXIg YW5kIGNsZWFuZXIuDQoNCklmIHdlIGFzc3VtZSB0aGF0IHJlZGlyZWN0IGJhc2VkIG9uIHRoZSBp bml0aWF0b3IgaWRlbnRpdHkgd2lsbCBiZQ0KYSBzb21ld2hhdCByZWxldmFudCB1c2UgY2FzZSwg cHV0dGluZyBSRURJUkVDVCBpbiBJS0VfQVVUSCByZXNwb25zZQ0KYXZvaWRzIHRoZSBzbGlnaHRs eSB3ZWlyZCAid2hhdCB0aGUgaGVjayBJJ20gc3VwcG9zZWQgdG8gZG8ga25vdz8hIiANCnN0YXRl IG9uIHRoZSBjbGllbnQgYWZ0ZXIgcmVjZWl2aW5nIHRoZSBJS0VfQVVUSCByZXNwb25zZSBidXQN CmJlZm9yZSBzZWVpbmcgdGhlIElORk9STUFUSU9OQUwgcmVxdWVzdC4NCg0KQmVzdCByZWdhcmRz LA0KUGFzaQ== From Pasi.Eronen@nokia.com Tue Mar 10 06:00:04 2009 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 B5B203A6ADB for ; Tue, 10 Mar 2009 06:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 ilBPAbmJP0zp for ; Tue, 10 Mar 2009 06:00:04 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id AB5EC3A682D for ; Tue, 10 Mar 2009 06:00:03 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2AD0Rpo019751; Tue, 10 Mar 2009 15:00:34 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Mar 2009 15:00:29 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Mar 2009 15:00:24 +0200 Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 10 Mar 2009 14:00:24 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Tue, 10 Mar 2009 14:00:24 +0100 From: To: Date: Tue, 10 Mar 2009 14:00:27 +0100 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 Thread-Index: Acmd+o80LWSERRCRSWW26KLO9SzXaQDhVdcQ Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F1E98C56@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 10 Mar 2009 13:00:24.0950 (UTC) FILETIME=[2D969960:01C9A180] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 10 Mar 2009 13:00:04 -0000 VmlqYXkgRGV2YXJhcGFsbGkgd3JvdGU6DQoNCj4gPiAtIFNlY3Rpb24gNi4xLzYuMi82LjM6IHNo b3VsZCBzYXkgdGhhdCBQcm90b2NvbCBJRCBpcyBzZXQgdG8gemVyby4NCj4gDQo+IEZpeGVkLg0K DQpPbmUgbml0OiB0aGUgdGV4dCBpbiB2ZXJzaW9uIC0wNSBzYXlzICJQcm90b2NvbCBJRCBzaG91 bGQgYmUgDQpzZXQgdG8gMCIuIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUganVzdCAiaXMgc2V0IHRv IDAiIChvcg0KcGVyaGFwcyAiTVVTVCBiZSBzZXQgdG8gMCIpDQoNCkJlc3QgcmVnYXJkcywNClBh c2k= From Pasi.Eronen@nokia.com Tue Mar 10 06:14:07 2009 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 308973A6A28 for ; Tue, 10 Mar 2009 06:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 k2GuxpWntuSq for ; Tue, 10 Mar 2009 06:14:06 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 30A023A69B2 for ; Tue, 10 Mar 2009 06:14:05 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2ADENSK003625; Tue, 10 Mar 2009 08:14:39 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Mar 2009 15:14:24 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Mar 2009 15:14:19 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 10 Mar 2009 14:14:15 +0100 From: To: Date: Tue, 10 Mar 2009 14:14:20 +0100 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 Thread-Index: AcmcFP5aSwpuXvYwQQOo+mFmSfiHZAFa7qdQ Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F1E98C87@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <18861.19717.483315.281468@fireball.kivinen.iki.fi> In-Reply-To: <18861.19717.483315.281468@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 X-OriginalArrivalTime: 10 Mar 2009 13:14:19.0740 (UTC) FILETIME=[1F2971C0:01C9A182] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 10 Mar 2009 13:14:07 -0000 Tero Kivinen wrote: > > I have one somewhat substantial concern with the document: it > > needs to be much clearer about what information is updated by the > > received REDIRECT messages, and what is not. >=20 > Never really thought that issue. I myself assumed that both GWs are > identical, i.e. they return same ID, and use same authentication > data (i.e. if PSK, both use same PSK, if certs, both authenticate > against same trust anchor and use same identity in cert, but not > necessarely same private key). I think that's roughly what I initially assumed, too. In this case, the REDIRECT payload is redirecting the VPN client from one IP address to another, but within the same "responder identity" (not from one responder identity to another) .=20 (Here "responder identity" can be single physical box with several=20 addresses, or multiple physical boxes configured to "look like=20 one" -- the client doesn't have to know which.) > > One possible answer would be that REDIRECT is interpreted just as > > data received from DNS, so all the gateways (redirecting among > > each other) would send same IDr value. >=20 > I think this is the easiest way to make sure redirect is secure. I agree -- and if we settle on this approach, we might want to rename the "New Responder GW Identity" field (in REDIRECT payload) to something like "New Responder Transport Address" -- since the IKE identity is not changed, only the address used for transporting IKE messages. I spent some time in trying to figure out how to specify the other approach (redirect to different "responder identity") securely, but couldn't really come up with anything that would work and be consistent with the RFC 4301 model... so at the very least, taking that approach will mean more work before we're done. Best regards, Pasi= From Pasi.Eronen@nokia.com Tue Mar 10 06:25:42 2009 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 3968B3A6AD5 for ; Tue, 10 Mar 2009 06:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 NJmiCdiah1Gy for ; Tue, 10 Mar 2009 06:25:41 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 304723A6A9C for ; Tue, 10 Mar 2009 06:25:40 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2ADPXS7014726; Tue, 10 Mar 2009 08:26:10 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Mar 2009 15:24:48 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Mar 2009 15:24:43 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 10 Mar 2009 14:24:42 +0100 From: To: , Date: Tue, 10 Mar 2009 14:24:43 +0100 Thread-Topic: Issue #44: Remove IPv6 NBNS Thread-Index: AcmcG6ljSt9nszaQS5ei4CBtl7PxFQFZ5qGQ Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F1E98CAD@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6C@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6C@il-ex01.ad.checkpoint.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_808FD6E27AD4884E94820BC333B2DB7727F1E98CADNOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 10 Mar 2009 13:24:43.0263 (UTC) FILETIME=[92CF80F0:01C9A183] X-Nokia-AV: Clean Subject: Re: [IPsec] Issue #44: Remove IPv6 NBNS 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, 10 Mar 2009 13:25:42 -0000 --_000_808FD6E27AD4884E94820BC333B2DB7727F1E98CADNOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Tero here; if NBNS for IPv6 is not even defined, and nobody co= uld have implemented this part of RFC 4306, then just removing the whole at= tribute (and marking the number RESERVED) sounds like a good way forward. Best regards, Pasi ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of e= xt Yaron Sheffer Sent: 03 March, 2009 20:18 To: ipsec@ietf.org Subject: [IPsec] Issue #44: Remove IPv6 NBNS Sec. 3.15.1: o INTERNAL_IP6_NBNS - {{ Clarif-6.6 }} NetBIOS is not defined = for IPv6; therefore, INTERNAL_IP6_NBNS is also unspecified and is only reta= ined for compatibility with RFC 4306. I think there is no point of keeping the 'compatibility with RFC 4306' for feature that cannot be used. I would si= mply remove the whole INTERNAL_IP6_NBNS and mark it RESERVED. Paul: Not done. This should be discussed on the mailing list. Yaron: I support Tero on this. Input from IPv6 implementors would be most u= seful. --_000_808FD6E27AD4884E94820BC333B2DB7727F1E98CADNOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I agree with Tero here; if NBNS for IPv6 is not ev= en=20 defined, and nobody could have implemented this part of RFC 4306, then just= =20 removing the whole attribute (and marking the number RESERVED) sounds like = a=20 good way forward.
 
Best regards,
Pasi

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of ext Yaron=20 Sheffer
Sent: 03 March, 2009 20:18
To:=20 ipsec@ietf.org
Subject: [IPsec] Issue #44: Remove IPv6=20 NBNS

RFC= =20 4306.

RFC 4306' for feature tha= t=20 cannot be used. I would simply remove the whole INTERNAL_IP6_NBNS and mar= k it=20 RESERVED.

Yaron: I support Tero on th= is.=20 Input from IPv6 implementors would be most=20 useful.

--_000_808FD6E27AD4884E94820BC333B2DB7727F1E98CADNOKEUMSG01mgd_-- From paul.hoffman@vpnc.org Tue Mar 10 10:43:39 2009 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 E93763A69CD for ; Tue, 10 Mar 2009 10:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 jIe4Ho+rxrCy for ; Tue, 10 Mar 2009 10:43:39 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A983E3A68FB for ; Tue, 10 Mar 2009 10:43:38 -0700 (PDT) Received: from [165.227.249.202] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2AHiB99045707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Mar 2009 10:44:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 10 Mar 2009 10:44:09 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Agenda for San Francisco, first cut 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, 10 Mar 2009 17:43:40 -0000 Yaron and I welcome comments on this. --Paul Hoffman Welcome, scribe, bluesheets, issue tracking process - 5 mins Roadmap - 15 mins Session Resumption - 15 mins - draft-ietf-ipsecme-ikev2-resumption ESP NULL visibility - 15 mins - draft-ietf-ipsecme-traffic-visibility Redirect - 15 mins - draft-ietf-ipsecme-ikev2-redirect Out-of-scope IPsec topic (to be determined) - 15 mins IKEv2bis open issues - remaining time - draft-ietf-ipsecme-ikev2bis From vijay@wichorus.com Tue Mar 10 11:06:31 2009 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 267C93A6A49 for ; Tue, 10 Mar 2009 11:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 ocgK2EQ0fh3h for ; Tue, 10 Mar 2009 11:06:30 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 4FD983A6407 for ; Tue, 10 Mar 2009 11:06:30 -0700 (PDT) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id RQ8e1b0050S2fkCA1W70Qz; Tue, 10 Mar 2009 18:07:00 +0000 Received: from [10.166.254.110] ([99.51.129.145]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id RW6s1b00S38Mh0K8VW6xFk; Tue, 10 Mar 2009 18:07:04 +0000 Message-ID: <49B6BA4B.5060902@wichorus.com> Date: Tue, 10 Mar 2009 11:06:51 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727F1E98C56@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F1E98C56@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 10 Mar 2009 18:06:31 -0000 Pasi.Eronen@nokia.com wrote: > Vijay Devarapalli wrote: > >>> - Section 6.1/6.2/6.3: should say that Protocol ID is set to zero. >> Fixed. > > One nit: the text in version -05 says "Protocol ID should be > set to 0". I think this should be just "is set to 0" (or > perhaps "MUST be set to 0") Changed it to "... MUST be set to 0 ..." Vijay From latten@austin.ibm.com Tue Mar 10 14:24:55 2009 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 858113A6850 for ; Tue, 10 Mar 2009 14:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJKJ2e6oJaks for ; Tue, 10 Mar 2009 14:24:54 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 7ED8C3A69A7 for ; Tue, 10 Mar 2009 14:24:54 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n2ALMs2u007123 for ; Tue, 10 Mar 2009 17:22:54 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2ALPTVg188630 for ; Tue, 10 Mar 2009 17:25:29 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2ALPSNk002099 for ; Tue, 10 Mar 2009 17:25:29 -0400 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n2ALPSJl002070; Tue, 10 Mar 2009 17:25:28 -0400 Received: from faith.austin.ibm.com (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id n2ALPRm6039440; Tue, 10 Mar 2009 16:25:28 -0500 Received: from faith.austin.ibm.com (localhost.localdomain [127.0.0.1]) by faith.austin.ibm.com (8.14.2/8.12.8) with ESMTP id n2ALGZN5013939; Tue, 10 Mar 2009 16:16:35 -0500 Received: (from jml@localhost) by faith.austin.ibm.com (8.14.2/8.14.2/Submit) id n2ALGZD0013938; Tue, 10 Mar 2009 16:16:35 -0500 X-Authentication-Warning: faith.austin.ibm.com: jml set sender to latten@austin.ibm.com using -f From: Joy Latten To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6D@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6D@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Mar 2009 16:16:33 -0500 Message-Id: <1236719793.3129.36.camel@faith.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Issue #48: Change text re: document status vs. older RFCs 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, 10 Mar 2009 21:24:55 -0000 On Tue, 2009-03-03 at 20:18 +0200, Yaron Sheffer wrote: > Yaron: Sec. 1: 'intended to replace': the status WRT IKEv1 and IKEv2 > is obviously very different. I suggest:=20 >=20 > [4306] has obsoleted the IKEv1 document set. The current document > replaces [IKEv2] and [Clarif] by a single unified description of the > IKEv2 protocol.=20 >=20 > Paul: I think the current [wording] is actually more correct than the > proposed rewording.=20 >=20 > Yaron: the text has been changed somewhat in the meantime. The current > text has: >=20 > =20 >=20 > =E2=80=A6 This memo describes such a protocol -- the Internet Key Exchang= e > (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI], 2408 > [ISAKMP], and 2409 [IKEV1]. IKEv2 replaced all of those RFCs. IKEv2 > was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif] (RFC > 4718). This document replaces and updates RFC 4306 and RFC 4718. >=20 > =20 This sounds good to me and straight forward. >=20 > I suggest to append this sentence to the above paragraph: >=20 > =20 >=20 > IKEv2 was a major, non-backward compatible change to the IKE protocol; > in contrast, the current document is primarily a clarification of > IKEv2, making a minimum number of necessary changes to the protocol. >=20 As an implementer who has had to read rfcs often, I had to read this sentence more than once to understand. Would something like below be easier? IKEv2 was a non-backward compatible change to the IKE protocol.=20 In contrast the current document not only provides a clarification of IKEv2, but makes minimum change to the IKE protocol.=20 regards, Joy From latten@austin.ibm.com Tue Mar 10 16:25:49 2009 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 018A73A69C7 for ; Tue, 10 Mar 2009 16:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bmpuf87wBZ1 for ; Tue, 10 Mar 2009 16:25:48 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 17ADE3A6898 for ; Tue, 10 Mar 2009 16:25:47 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n2ANP1gn009505 for ; Tue, 10 Mar 2009 17:25:01 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2ANQMYY205366 for ; Tue, 10 Mar 2009 17:26:22 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2ANQMnY014078 for ; Tue, 10 Mar 2009 17:26:22 -0600 Received: from austin.ibm.com (netmail1.austin.ibm.com [9.41.248.175]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n2ANQMun014074; Tue, 10 Mar 2009 17:26:22 -0600 Received: from faith.austin.ibm.com (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id n2ANQLhP027810; Tue, 10 Mar 2009 18:26:21 -0500 Received: from faith.austin.ibm.com (localhost.localdomain [127.0.0.1]) by faith.austin.ibm.com (8.14.2/8.12.8) with ESMTP id n2ANHSSi018850; Tue, 10 Mar 2009 18:17:28 -0500 Received: (from jml@localhost) by faith.austin.ibm.com (8.14.2/8.14.2/Submit) id n2ANHSow018849; Tue, 10 Mar 2009 18:17:28 -0500 X-Authentication-Warning: faith.austin.ibm.com: jml set sender to latten@austin.ibm.com using -f From: Joy Latten To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6E@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC6E@il-ex01.ad.checkpoint.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 10 Mar 2009 18:17:27 -0500 Message-Id: <1236727047.3129.68.camel@faith.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Issue #52: Pipelining: interop between supporting and non-supporting peers 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, 10 Mar 2009 23:25:49 -0000 On Tue, 2009-03-03 at 20:14 +0200, Yaron Sheffer wrote: > Yaron: > > 2.3: The first paragraph contains an apparent contradiction. It > mentions that pipelining is done 'if the other endpoint has indicated > its ability to handle such requests' and then goes on to describe how > a pipelining implementation can interoperate with a non-pipelining > one. Which should be trivial if the pipelining side knows what the > other side is capable of. > > Paul: Not done, definitely worth discussing on the list. > I thought the paragraph was describing two possible ways to send requests. From what I understood, the SET_WINDOW_SIZE only indicated the capability, it did not mean the endpoint receiving the notification had to send requests that way. That it could send one request and wait for a response before sending another request. Which made me think the last sentence in the 1st paragraph of section 2.3 "Certain rules must be followed to ensure interoperability between implementations using different strategies." was confusing. If the sender of the notification is only indicating a capability, and the receiver of the notification decides to continue to send a request and wait for a response, then I am not sure I understand how that is that an interoperability issue? regards, Joy From Pasi.Eronen@nokia.com Wed Mar 11 04:44:45 2009 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 584FE3A689B for ; Wed, 11 Mar 2009 04:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 cIE7jN9upN1k for ; Wed, 11 Mar 2009 04:44:41 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 779263A6881 for ; Wed, 11 Mar 2009 04:44:41 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2BBigRZ001007; Wed, 11 Mar 2009 06:45:16 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 13:44:31 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 13:44:31 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 13:44:26 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 11 Mar 2009 12:44:25 +0100 From: To: Date: Wed, 11 Mar 2009 12:44:26 +0100 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 Thread-Index: AcmQG11xz3Y00zEpSza195DYpuB4qgLVe3mQAWVyzAAATYAZgA== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F1E99700@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: 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 X-OriginalArrivalTime: 11 Mar 2009 11:44:26.0211 (UTC) FILETIME=[BAC7FB30:01C9A23E] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 11 Mar 2009 11:44:45 -0000 Vijay Devarapalli wrote: > I don't agree with the restriction that the original gateway and the > new gateway should have the same IDr. That is too restrictive. For > example, it should be possible for gw1 to redirect the client to > gw2, with the two gateways having two distinct FQDNs. Right... but if the client does not have a PAD entry for gw2's IDr, then the IKE negotiation will fail. (I guess we're not considering updating the PAD based on REDIRECTs.) (BTW, note that "having same IDr" is not exactly the same thing as "having same FQDN" -- gw1.example.com and gw2.foobar.example are clearly distinct FQDNs from DNS-point-of-view, but they might or might not be distinct "principals" from IPsec PAD point of view.) > It is okay with me to recommend similar authentication mechanisms > for the original and new gateways. But I would prefer not use a > 'MUST' here. I think this needs to be phrased in terms of the RFC 4301 PAD=20 (and possibly the "selecting right peer for SA function"). Best regards, Pasi= From Pasi.Eronen@nokia.com Wed Mar 11 04:52:35 2009 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 E9EA43A6B9F for ; Wed, 11 Mar 2009 04:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 WDn1JxZHYW8t for ; Wed, 11 Mar 2009 04:52:35 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id A695A3A6BA1 for ; Wed, 11 Mar 2009 04:52:34 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2BBqE4I008111; Wed, 11 Mar 2009 06:53:07 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 13:52:40 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 13:52:40 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 11 Mar 2009 12:52:39 +0100 From: To: , Date: Wed, 11 Mar 2009 12:52:38 +0100 Thread-Topic: Issue #6: DH proposal and INVALID_KE_PAYLOAD Thread-Index: AcmcGhJBhYxTylilRFakOH4OnG/jWAGJTvBQ Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F1E99712@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC72@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC72@il-ex01.ad.checkpoint.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_808FD6E27AD4884E94820BC333B2DB7727F1E99712NOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 11 Mar 2009 11:52:40.0302 (UTC) FILETIME=[E14848E0:01C9A23F] X-Nokia-AV: Clean Subject: Re: [IPsec] Issue #6: DH proposal and INVALID_KE_PAYLOAD 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, 11 Mar 2009 11:52:36 -0000 --_000_808FD6E27AD4884E94820BC333B2DB7727F1E99712NOKEUMSG01mgd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Earlier, Section 1.3 also had this bug (but it was fixed in -02). I'd sugge= st rephrasing this the same way as 1.3: OLD: "If the guess turns out to be wrong, the responder will indicate the correc= t group in the response and the initiator SHOULD pick an element of that gr= oup for its KE value when retrying the first message." NEW: "If the responder selects a proposal using a different Diffie-Hellman group= (other than NONE), the responder will indicate the correct group in the re= sponse and the initiator SHOULD pick an element of that group for its KE va= lue when retrying the first message." Best regards, Pasi ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of e= xt Yaron Sheffer Sent: 03 March, 2009 20:18 To: ipsec@ietf.org Subject: [IPsec] Issue #6: DH proposal and INVALID_KE_PAYLOAD http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/6 Yaron: Section 3.3.6, second paragraph: Assume a CREATE_CHILD_SA packet is receive= d with SA payload proposal 1 D-H=3D2 ... proposal 2 D-H=3D0 ... KE payload = D-H=3D2 ... Assume the responder wants to pick proposal number 2. Because t= he KE payload refers to D-H=3D2, the responder must return INVALID_KE_PAYLO= AD, event though the responder could just select proposal 2 and omit the KE= payload in the response. Paul: Sending INVALID_KE_PAYLOAD in this case certainly wasn't the intent, but yo= u're right that the text doesn't explicitly say this. Yaron: Should we say something like: An exception is the case where one of the proposals offered is for D-H grou= p NONE. In this case, the responder MUST ignore the initiator=92s KE payloa= d and omit the KE payload from the response. --_000_808FD6E27AD4884E94820BC333B2DB7727F1E99712NOKEUMSG01mgd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Earlier, Section 1.3 also had this bug (but it was= fixed in=20 -02). I'd suggest rephrasing
this the same way as 1.3:

OLD:
 
"If the guess turns out to be wrong, the= =20 responder will indicate the correct= group=20 in the response and the initiator SHOULD pick an=20 element of that group for its KE value when retrying the first message."
 
NEW= :
 
"If the responder selects a proposal usin= g a=20 different Diffie-Hellman group (oth= er than=20 NONE), the responder will indicate = the=20 correct group in the response and the initiator SHOULD pick an element of that group for its KE value w= hen=20 retrying the first message."
Best regards,
Pasi

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of ext Yaron=20 Sheffer
Sent: 03 March, 2009 20:18
To:=20 ipsec@ietf.org
Subject: [IPsec] Issue #6: DH proposal and=20 INVALID_KE_PAYLOAD

http://trac.= tools.ietf.org/wg/ipsecme/trac/ticket/6

 

Yaron:

Paul:

Yaron:

 

--_000_808FD6E27AD4884E94820BC333B2DB7727F1E99712NOKEUMSG01mgd_-- From Pasi.Eronen@nokia.com Wed Mar 11 05:12:03 2009 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 594433A6970 for ; Wed, 11 Mar 2009 05:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 sikYtAytZKAr for ; Wed, 11 Mar 2009 05:12:02 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 220A23A6BAB for ; Wed, 11 Mar 2009 05:12:01 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2BCC1Ch001049; Wed, 11 Mar 2009 14:12:33 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 14:12:31 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 14:12:21 +0200 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 11 Mar 2009 13:12:21 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Wed, 11 Mar 2009 13:12:20 +0100 From: To: , , Date: Wed, 11 Mar 2009 13:12:17 +0100 Thread-Topic: Issue #17: Checking of the other peer's IKE SPI Thread-Index: AcmcGrigFobKfatMRA2+XtjQiNNOLwGJWaKg Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F1E9975F@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC74@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC74@il-ex01.ad.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 X-OriginalArrivalTime: 11 Mar 2009 12:12:21.0824 (UTC) FILETIME=[A1863C00:01C9A242] X-Nokia-AV: Clean Subject: Re: [IPsec] Issue #17: Checking of the other peer's IKE SPI 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, 11 Mar 2009 12:12:03 -0000 Yaron and Tero, Hmm... it seems changing your own IKE SPI during an IKE_SA does not work anyway, so if you get a packet where the peer's SPI is different (than what it used for this IKE_SA earlier), it did not come from=20 a spec-compliant peer. =20 The question is whether we should require the recipient to check that the peer's SPI has not changed. To me, it looks like this would not be an interoperability issue (the peer is doing something outside the spec, so it can't expect any particular behavior from us)...=20 =20 Tero, how did you encounter this in the interops? (And was the node sending this buggy, or did it consider itself to be behaving according to the spec?) =20 If it's not an interop issue, and not a security issue, then I'm not sure if mandating such check is needed. But are there some=20 security implications? Best regards, Pasi > -----Original Message----- > From: Yaron Sheffer > Sent: 03 March, 2009 20:18 > To: ipsec@ietf.org > Subject: [IPsec] Issue #17: Checking of the other peer's IKE SPI >=20 > Sec. 2.6:=20 >=20 > Unlike ESP and AH where only the recipient's SPI appears in the > header of a message, in IKE the sender's SPI is also sent in every > message. Since the SPI chosen by the original initiator of the > IKE_SA is always sent first, an endpoint with multiple IKE_SAs open > that wants to find the appropriate IKE_SA using the SPI it assigned > must look at the I(nitiator) Flag bit in the header to determine > whether it assigned the first or the second eight octets. >=20 > Tero: >=20 > Our implementation originally only checked its own SPI half, and > didn't verify that the other ends SPI half didn't change. This was > found out in the interop, and we fixed it to check the other ends > SPI also, but I wonder should we say one way or the other here? Also > what SPI should the response have, i.e. the SPIs from the request, > or the SPIs from the original IKE SA creation. I think it might be > easier to just say, that implementations can use their own SPI to > find the IKE SA data, but MUST also check that the other ends SPI > matches the SPIs stored with IKE SA data. >=20 > Paul: Not done. This is interesting, but should be discussed on the > list.= From Pasi.Eronen@nokia.com Wed Mar 11 05:24:04 2009 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 B63E63A6970 for ; Wed, 11 Mar 2009 05:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 gzBJba+GkmiY for ; Wed, 11 Mar 2009 05:24:04 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id BB3FD3A6810 for ; Wed, 11 Mar 2009 05:24:03 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2BCNk6n004967; Wed, 11 Mar 2009 07:24:36 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 14:24:10 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 14:24:09 +0200 Received: from NOK-AM1MHUB-05.mgdnok.nokia.com (65.54.30.9) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 11 Mar 2009 13:24:08 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by NOK-AM1MHUB-05.mgdnok.nokia.com ([65.54.30.9]) with mapi; Wed, 11 Mar 2009 13:24:08 +0100 From: To: , Date: Wed, 11 Mar 2009 13:24:04 +0100 Thread-Topic: [IPsec] Issue #35: INVALID_SPI: does the SPI determine the protocol (ESP/AH)? Thread-Index: AcmcGuuLfJ72zRtOTB2DUFgFk4rLQwGKHeiQ Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F1E99780@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC75@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC75@il-ex01.ad.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 X-OriginalArrivalTime: 11 Mar 2009 12:24:09.0738 (UTC) FILETIME=[477956A0:01C9A244] X-Nokia-AV: Clean Subject: Re: [IPsec] Issue #35: INVALID_SPI: does the SPI determine the protocol (ESP/AH)? 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, 11 Mar 2009 12:24:04 -0000 Hmm... it seems Tero is right; since the SPI is in the notification data (not the "SPI" field of the Notify payload), the "Protocol ID" field would be zero, and the recipient doesn't know whether the SPI was for ESP or AH. I think Tero's proposal about just noting this fact (i.e. not=20 changing how this work) would be OK and sufficient. Best regards, Pasi > -----Original Message----- > From: Yaron Sheffer > Sent: 03 March, 2009 20:18 > To: ipsec@ietf.org > Subject: [IPsec] Issue #35: INVALID_SPI: does the SPI determine the proto= col (ESP/AH)? >=20 > 1.5. Informational Messages outside of an IKE_SA=20 >=20 > ...=20 >=20 > {{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE > INFORMATIONAL exchange when a node receives an ESP or AH packet with > an invalid SPI. The Notification Data contains the SPI of the > invalid packet. This usually indicates a node has rebooted and > forgotten an SA. If this Informational Message is sent outside the > context of an IKE_SA, it should only be used by the recipient as a > 'hint' that something might be wrong (because it could easily be > forged). >=20 > Tero: >=20 > If the notification data is used for the SPI of the invalid packet, > how can the recipient of such notify know whether that SPI was for > ESP or AH? As far as I can see, it cannot, but I think it does not > matter as SPIs are now supposed to be unique (i.e. protocol is no > loger include as key). Perhaps we should just note this fact here? >=20 > Paul: Not done. This is interesting, but should be discussed on the list.= = From ynir@checkpoint.com Wed Mar 11 05:25:12 2009 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 270A43A6810 for ; Wed, 11 Mar 2009 05:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 IAm-r7STJQRz for ; Wed, 11 Mar 2009 05:25:10 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 633893A687D for ; Wed, 11 Mar 2009 05:25:09 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E31EA2CC003; Wed, 11 Mar 2009 14:25:44 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 3424B2CC002; Wed, 11 Mar 2009 14:25:42 +0200 (IST) X-CheckPoint: {49B7ACF4-0-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n2BCPf16004923; Wed, 11 Mar 2009 14:25:41 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 11 Mar 2009 14:25:41 +0200 From: Yoav Nir To: "Pasi.Eronen@nokia.com" , "vijay@wichorus.com" Date: Wed, 11 Mar 2009 14:26:19 +0200 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 Thread-Index: AcmQG11xz3Y00zEpSza195DYpuB4qgLVe3mQAWVyzAAATYAZgAAAjSaw Message-ID: <9FB7C7CE79B84449B52622B506C78036133299F197@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727F1E99700@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F1E99700@NOK-EUMSG-01.mgdnok.nokia.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 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 11 Mar 2009 12:25:12 -0000 Pasi.Eronen@nokia.com wrote: >=20 > Vijay Devarapalli wrote: >=20 > > I don't agree with the restriction that the original=20 > gateway and the=20 > > new gateway should have the same IDr. That is too restrictive. For=20 > > example, it should be possible for gw1 to redirect the=20 > client to gw2,=20 > > with the two gateways having two distinct FQDNs. >=20 > Right... but if the client does not have a PAD entry for=20 > gw2's IDr, then the IKE negotiation will fail. (I guess we're=20 > not considering updating the PAD based on REDIRECTs.) I agree that we have to assume that gw2 is in the PAD. It could be the same= entry as gw1, or it could be different, but it has to be in the PAD. If g= w1 redirects the client to a gateway that is not in the PAD, then the clien= t must log or report, and fail. > (BTW, note that "having same IDr" is not exactly the same=20 > thing as "having same FQDN" -- gw1.example.com and=20 > gw2.foobar.example are clearly distinct FQDNs from=20 > DNS-point-of-view, but they might or might not be distinct=20 > "principals" from IPsec PAD point of view.) >=20 > > It is okay with me to recommend similar authentication=20 > mechanisms for=20 > > the original and new gateways. But I would prefer not use a 'MUST'=20 > > here. >=20 > I think this needs to be phrased in terms of the RFC 4301 PAD=20 > (and possibly the "selecting right peer for SA function"). RFC 4301 does not require that each SPD entry be associated with a single P= AD entry. It's a many-to-many relationship. The section on named SPDs speci= fically says that an SPD entry may have multiple names. Section 4.4.3.3 sa= ys that "If the entry indicates that child SAs traffic selectors are to be = used, then an additional data element is required, in the form of IPv4 and/= or IPv6 address ranges." It does not say that two entries cannot have the s= ame IDs. This works fine if two gateways (at different addresses) protect the same n= etworks (an example would be two geographically distinct sites, each with i= ts own gateway, and an MPLS link between them). If the redirect-to gateway is in the PAD, but either does not protect the s= ame networks at all, or has a partial overlap in protected networks, then w= e have a problem, because if the client is setting up a child SA in order t= o reach host A, protected by gw1 but not by gw2, then it's not clear what s= electors should be used with gw2, and whether the whole exercise has any va= lue. Perhaps instead of requiring "having the same Idr" we need to require "havi= ng the same SPD entries", except maybe SPDs that cover the gateways themsel= ves. Yoav Email secured by Check Point From kivinen@iki.fi Wed Mar 11 05:57:45 2009 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 9B5063A6A74 for ; Wed, 11 Mar 2009 05:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 06tUNNgXfiAr for ; Wed, 11 Mar 2009 05:57:44 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 6028228C1CA for ; Wed, 11 Mar 2009 05:57:42 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n2BCwAmY006430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2009 14:58:10 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n2BCw8rN007753; Wed, 11 Mar 2009 14:58:08 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18871.46432.577501.495334@fireball.kivinen.iki.fi> Date: Wed, 11 Mar 2009 14:58:08 +0200 From: Tero Kivinen To: Vijay Devarapalli In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 19 min X-Total-Time: 24 min Cc: IPsecme WG , Yoav Nir , paul.hoffman@vpnc.org Subject: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04) 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, 11 Mar 2009 12:57:45 -0000 Vijay Devarapalli writes: > There at least three people who think that the IKE_AUTH response > message should itself contain the REDIRECT payload. I went through the > email exchange between Fan and Tero. There was no new information > that came out of that discussion for me to make this change in the > draft. > > Does any one else have an opinion? > > Otherwise I suggest the WG chairs to make a call on this. > > Both solutions, 1) sending a REDIRECT payload in the IKE_AUTH response > 2) sending a NO_ADDITIONAL_SAS in the IKE_AUTH response followed by a > REDIRECT message, would work. If you add text allowing REDIRECT with IKE_AUTH, then add also text explaining how REDIRECT is used with other different extensions, including EAP and multi auth. I.e. what happens if the server returns REDIRECT before the first EAP exchange is finished, or what happens if the server returns REDIRECT after the first EAP has succeeded, but before the AUTH payload exchange after that, or what happens if server returns REDIRECT even when the client wants to do another AUTH negotiation etc. I.e. if we take following example from the RFC4739: Initiator Responder ----------- ----------- 1. HDR, SA, KE, Ni --> <-- 2. HDR, SA, KE, Nr, [CERTREQ], N(MULTIPLE_AUTH_SUPPORTED) 3. HDR, SK { IDi, [CERTREQ+], [IDr], SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) } --> <-- 4. HDR, SK { IDr, [CERT+], AUTH, EAP(Request) } 5. HDR, SK { EAP(Response) } --> <-- 6. HDR, SK { EAP(Request) } 7. HDR, SK { EAP(Response) } --> <-- 8. HDR, SK { EAP(Success) } 9. HDR, SK { AUTH, N(ANOTHER_AUTH_FOLLOWS) } --> <-- 10. HDR, SK { AUTH } 11. HDR, SK { IDi } --> <-- 12. HDR, SK { EAP(Request) } 13. HDR, SK { EAP(Response) } --> <-- 14. HDR, SK { EAP(Request) } 15. HDR, SK { EAP(Response) } --> <-- 16. HDR, SK { EAP(Success) } 17. HDR, SK { AUTH } --> <-- 18. HDR, SK { AUTH, SA, TSi, TSr } In which packets is the REDIRECT allowed. Is it only allowed in the final 18th message? Is it also allowed in packet 10? Can it be sent during any time of the EAP exachanges? This is actually something that is bit unclear already in the RFC4306. For notification payloads belonging to the IPsec SA (IPCOMP_SUPPORTED, ADDITIONAL_TS_POSSIBLE, USE_TRANSPORT_MODE, ESP_TFC_PADDING_NOT_SUPPORTED, NON_FIRST_FRAGMENTS_ALSO), it is quite logical that the payloads containing SA and TS* payloads are the ones where they should be in, but for example ESP_TFC_PADDING_NOT_SUPPORTED and NON_FIRST_FRAGMENTS_ALSO do not contain explicit text listing where they should be. For others there are other defined places (i.e. HTTP_CERT_LOOKUP_SUPPORTED should be in the payload containing CERTREQ, REKEY_SA should be same packet as SA payload, COOKIE and NAT_DETECTION_*_IP are used only in IKE_SA_INIT). For status notifications like INITIAL_CONTACT and SET_WINDOW_SIZE there is no defined or logical place to send them, so most likely they can be in any packet during IKE_AUTH exchange (or after that as separate INFORMATIONAL exchange). The RFC4478 defines one more status notification i.e. AUTH_LIFETIME and that is defined to be in last IKE_AUTH message, or as separate INFORMATIONAL exchange. MOBIKE (RFC 4555) defines that the new status notifications which can be in IKE_AUTH (MOBIKE_SUPPORTED and ADDITIONAL_IP*_ADDRESSES) are in the IKE_AUTH message containing the SA payload. I assume that REDIRECT is going to be status notification, which means that the IKE SA is created even when that is returned during IKE_AUTH, and then the resulting IKE_AUTH still needs to be deleted with separate INFORMATIONAL exchange containing delete payloads. -- kivinen@iki.fi From kivinen@iki.fi Wed Mar 11 06:29:36 2009 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 6E6063A6980 for ; Wed, 11 Mar 2009 06:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 GPUl9BlaCUht for ; Wed, 11 Mar 2009 06:29:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id F29FB3A6A2B for ; Wed, 11 Mar 2009 06:29:34 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n2BDU5Y2009849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2009 15:30:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n2BDU5qF003745; Wed, 11 Mar 2009 15:30:05 +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: <18871.48349.182611.966945@fireball.kivinen.iki.fi> Date: Wed, 11 Mar 2009 15:30:05 +0200 From: Tero Kivinen To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F1E9975F@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC74@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727F1E9975F@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #17: Checking of the other peer's IKE SPI 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, 11 Mar 2009 13:29:36 -0000 Pasi.Eronen@nokia.com writes: > Yaron and Tero, > > Hmm... it seems changing your own IKE SPI during an IKE_SA does not > work anyway, so if you get a packet where the peer's SPI is different > (than what it used for this IKE_SA earlier), it did not come from > a spec-compliant peer. > > The question is whether we should require the recipient to check > that the peer's SPI has not changed. To me, it looks like this would > not be an interoperability issue (the peer is doing something outside > the spec, so it can't expect any particular behavior from us)... > > Tero, how did you encounter this in the interops? (And was the node > sending this buggy, or did it consider itself to be behaving according > to the spec?) The sender was TAHI project IKEv2 tester, and if I remember correctly they sent that on purpose and they expected the other end to detect that SPI changed, and not to continue because of that. Our code simply used our own SPI as that is sufficient to find the IKE SA and we didn't really care what was in the other ends SPI. I did add additional check to our code to check the other ends SPI and drop the packet if it is changed. > If it's not an interop issue, and not a security issue, then I'm > not sure if mandating such check is needed. But are there some > security implications? I agree that there is no real need to mandate such check, but if IKEv2 tester implementations are requiring such check that will be de-facto requirement to add such check, as otherwise you will not pass their tests. So for that it is interoperability issue, as you cannot pass their interoperability tests if you do not check it. So thats why I think it would be good to say that either it is valid to check only your own SPI or that you MUST check both spis. -- kivinen@iki.fi From latten@austin.ibm.com Wed Mar 11 11:37:44 2009 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 09C8D3A6810 for ; Wed, 11 Mar 2009 11:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyz3aCDKqzB3 for ; Wed, 11 Mar 2009 11:37:40 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id 2914528C116 for ; Wed, 11 Mar 2009 11:37:39 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n2BIaJut005817 for ; Wed, 11 Mar 2009 12:36:19 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2BIcExC172106 for ; Wed, 11 Mar 2009 12:38:15 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2BIcEOk004678 for ; Wed, 11 Mar 2009 12:38:14 -0600 Received: from austin.ibm.com (netmail1.austin.ibm.com [9.41.248.175]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n2BIcEbt004667; Wed, 11 Mar 2009 12:38:14 -0600 Received: from faith.austin.ibm.com (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id n2BIcD4G061306; Wed, 11 Mar 2009 13:38:13 -0500 Received: from faith.austin.ibm.com (localhost.localdomain [127.0.0.1]) by faith.austin.ibm.com (8.14.2/8.12.8) with ESMTP id n2BITH0u001516; Wed, 11 Mar 2009 13:29:17 -0500 Received: (from jml@localhost) by faith.austin.ibm.com (8.14.2/8.14.2/Submit) id n2BITHgO001515; Wed, 11 Mar 2009 13:29:17 -0500 X-Authentication-Warning: faith.austin.ibm.com: jml set sender to latten@austin.ibm.com using -f From: Joy Latten To: Pasi.Eronen@nokia.com In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F1E99780@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC75@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727F1E99780@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 11 Mar 2009 13:29:16 -0500 Message-Id: <1236796156.3129.85.camel@faith.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #35: INVALID_SPI: does the SPI determine the protocol (ESP/AH)? 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, 11 Mar 2009 18:37:44 -0000 On Wed, 2009-03-11 at 13:24 +0100, Pasi.Eronen@nokia.com wrote: > Hmm... it seems Tero is right; since the SPI is in the notification > data (not the "SPI" field of the Notify payload), the "Protocol ID" > field would be zero, and the recipient doesn't know whether the SPI > was for ESP or AH. > > I think Tero's proposal about just noting this fact (i.e. not > changing how this work) would be OK and sufficient. I could be missing something, but RFC4301, section 4.1 allows implementations to use the SPI in conjunction with the IPsec protocol for SA identification. So, if someone is in that latter case, wouldn't they have a problem? > > > -----Original Message----- > > From: Yaron Sheffer > > Sent: 03 March, 2009 20:18 > > To: ipsec@ietf.org > > Subject: [IPsec] Issue #35: INVALID_SPI: does the SPI determine the protocol (ESP/AH)? > > > > 1.5. Informational Messages outside of an IKE_SA > > > > ... > > > > {{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE > > INFORMATIONAL exchange when a node receives an ESP or AH packet with > > an invalid SPI. The Notification Data contains the SPI of the > > invalid packet. This usually indicates a node has rebooted and > > forgotten an SA. If this Informational Message is sent outside the > > context of an IKE_SA, it should only be used by the recipient as a > > 'hint' that something might be wrong (because it could easily be > > forged). > > > > Tero: > > > > If the notification data is used for the SPI of the invalid packet, > > how can the recipient of such notify know whether that SPI was for > > ESP or AH? As far as I can see, it cannot, but I think it does not > > matter as SPIs are now supposed to be unique (i.e. protocol is no > > loger include as key). Perhaps we should just note this fact here? > > > > Paul: Not done. This is interesting, but should be discussed on the list. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Wed Mar 11 12:35:06 2009 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 29ACC3A695E for ; Wed, 11 Mar 2009 12:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 8DVftZxW6IYW for ; Wed, 11 Mar 2009 12:35:05 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 147873A684C for ; Wed, 11 Mar 2009 12:35:04 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2BJZcKZ034275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2009 12:35:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F1E99700@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727F1E99700@NOK-EUMSG-01.mgdnok.nokia.com> Date: Wed, 11 Mar 2009 12:35:36 -0700 To: , From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ipsec@ietf.org Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 11 Mar 2009 19:35:06 -0000 At 12:44 PM +0100 3/11/09, wrote: >Vijay Devarapalli wrote: > >> I don't agree with the restriction that the original gateway and the >> new gateway should have the same IDr. That is too restrictive. For >> example, it should be possible for gw1 to redirect the client to >> gw2, with the two gateways having two distinct FQDNs. > >Right... but if the client does not have a PAD entry for gw2's IDr, >then the IKE negotiation will fail. (I guess we're not considering >updating the PAD based on REDIRECTs.) Co-chair-hat on: Right, we are not considering that currently. If we do consider it, it is a significant change to the document and we would want to do (at least) another WG last call. Co-chair-hat off: Right, and we should not consider that, given the difficulty of bounding the security considerations if we do so. --Paul Hoffman, Director --VPN Consortium From danmcd@sun.com Wed Mar 11 12:52:40 2009 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 2CA6328C15A for ; Wed, 11 Mar 2009 12:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 hTiTMCYKSTJg for ; Wed, 11 Mar 2009 12:52:34 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 966F128C0DF for ; Wed, 11 Mar 2009 12:52:34 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2BJrAD8027982 for ; Wed, 11 Mar 2009 19:53:10 GMT Received: from everywhere.east.sun.com (everywhere.East.Sun.COM [129.148.19.2]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n2BJrAhH006844 for ; Wed, 11 Mar 2009 15:53:10 -0400 (EDT) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n2BJjd05001763; Wed, 11 Mar 2009 15:45:39 -0400 (EDT) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n2BJjdS1001762; Wed, 11 Mar 2009 15:45:39 -0400 (EDT) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Wed, 11 Mar 2009 15:45:39 -0400 From: Dan McDonald To: Paul Hoffman Message-ID: <20090311194539.GD1391@sun.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727F1E99700@NOK-EUMSG-01.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Cc: ipsec@ietf.org Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 11 Mar 2009 19:52:40 -0000 On Wed, Mar 11, 2009 at 12:35:36PM -0700, Paul Hoffman wrote: > At 12:44 PM +0100 3/11/09, wrote: > >Right... but if the client does not have a PAD entry for gw2's IDr, > >then the IKE negotiation will fail. (I guess we're not considering > >updating the PAD based on REDIRECTs.) > Co-chair-hat off: > > Right, and we should not consider that, given the difficulty of bounding > the security considerations if we do so. I agree with Paul regardless of which hat he's wearing, but my reason for agreeing with him is more along the lines of his sans-hat look. :) Dan From vijay@wichorus.com Wed Mar 11 13:01:11 2009 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 BFB523A6B32 for ; Wed, 11 Mar 2009 13:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 hf-UYlCkrmW5 for ; Wed, 11 Mar 2009 13:01:06 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 096463A6809 for ; Wed, 11 Mar 2009 13:01:05 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA01.westchester.pa.mail.comcast.net with comcast id Rvhx1b06317dt5G51w1jS2; Wed, 11 Mar 2009 20:01:43 +0000 Received: from [10.166.254.110] ([99.51.129.145]) by OMTA13.westchester.pa.mail.comcast.net with comcast id Rw1X1b00438Mh0K3Zw1Z2A; Wed, 11 Mar 2009 20:01:41 +0000 Message-ID: <49B826A8.80306@wichorus.com> Date: Wed, 11 Mar 2009 13:01:28 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727F1E99700@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F1E99700@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 11 Mar 2009 20:01:11 -0000 Pasi.Eronen@nokia.com wrote: > Vijay Devarapalli wrote: > >> I don't agree with the restriction that the original gateway and the >> new gateway should have the same IDr. That is too restrictive. For >> example, it should be possible for gw1 to redirect the client to >> gw2, with the two gateways having two distinct FQDNs. > > Right... but if the client does not have a PAD entry for gw2's IDr, > then the IKE negotiation will fail. (I guess we're not considering > updating the PAD based on REDIRECTs.) Thats exactly what I am suggesting. :) This would be similar to a Mobile IPv6 mobile node creating a PAD entry for the home agent that it discovers using IETF-standardized mechanisms. I don't think we should require a Mobile IPv6 mobile node or a VPN client or a 3GPP client that uses I-WLAN and discovers a PDG [*] to have PAD entries configured for all the home agents/gateways/PDGs that it might attach to before hand. (* Apologies for using 3GPP terminology in the above. Pasi knows what I am talking about. If anyone wants to know more about this, please let me know. You might regret it later though. :) > (BTW, note that "having same IDr" is not exactly the same thing as > "having same FQDN" -- gw1.example.com and gw2.foobar.example are > clearly distinct FQDNs from DNS-point-of-view, but they might or might > not be distinct "principals" from IPsec PAD point of view.) If you put the FQDN in the PAD entry, you do have an issue, right? >> It is okay with me to recommend similar authentication mechanisms >> for the original and new gateways. But I would prefer not use a >> 'MUST' here. > > I think this needs to be phrased in terms of the RFC 4301 PAD > (and possibly the "selecting right peer for SA function"). Ok. Once we agree on a way forward, I can propose some text. Vijay From vijay@wichorus.com Wed Mar 11 13:07:22 2009 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 F0BE93A6A5D for ; Wed, 11 Mar 2009 13:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 aZToIqRc4HEX for ; Wed, 11 Mar 2009 13:07:17 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 0F3EC3A695E for ; Wed, 11 Mar 2009 13:07:16 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA04.westchester.pa.mail.comcast.net with comcast id RuuD1b00L17dt5G54w7uWR; Wed, 11 Mar 2009 20:07:54 +0000 Received: from [10.166.254.110] ([99.51.129.145]) by OMTA13.westchester.pa.mail.comcast.net with comcast id Rw7g1b00X38Mh0K3Zw7juf; Wed, 11 Mar 2009 20:07:52 +0000 Message-ID: <49B82819.9010901@wichorus.com> Date: Wed, 11 Mar 2009 13:07:37 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Paul Hoffman References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727F1E99700@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 11 Mar 2009 20:07:23 -0000 Paul Hoffman wrote: > At 12:44 PM +0100 3/11/09, wrote: >> Vijay Devarapalli wrote: >> >>> I don't agree with the restriction that the original gateway and the >>> new gateway should have the same IDr. That is too restrictive. For >>> example, it should be possible for gw1 to redirect the client to >>> gw2, with the two gateways having two distinct FQDNs. >> Right... but if the client does not have a PAD entry for gw2's IDr, >> then the IKE negotiation will fail. (I guess we're not considering >> updating the PAD based on REDIRECTs.) > > Co-chair-hat on: > > Right, we are not considering that currently. If we do consider it, it is a significant change to the document and we would want to do (at least) another WG last call. > > Co-chair-hat off: > > Right, and we should not consider that, given the difficulty of bounding the security considerations if we do so. There are environments where the client (e.g, Mobile IPv6 MN, 3GPP I-WLAN client) always discovers the gateways they need to attach to. They might get assigned different gateways based on what service they want to access, what their subscription profile is, etc.. In such environments, the PAD entries are created dynamically, but of course bound by the configuration on the mobile node. I think the REDIRECT mechanism is of limited use if you can only redirect to another gateway for which the mobile node already has a PAD entry. Note that Mobile IPv6 already allows the mobile node to discover home agents dynamically and then create PAD and SPD entries. These are already standards track documents. On starting another WG last call for the document if we make this change, I am fine with it. Vijay From vijay@wichorus.com Wed Mar 11 13:14:00 2009 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 538523A6A67 for ; Wed, 11 Mar 2009 13:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 Q-WV7k4XI-g0 for ; Wed, 11 Mar 2009 13:13:58 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 7EEEE3A6979 for ; Wed, 11 Mar 2009 13:13:58 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA04.westchester.pa.mail.comcast.net with comcast id RnLi1b00A0QuhwU54wEcB0; Wed, 11 Mar 2009 20:14:36 +0000 Received: from [10.166.254.110] ([99.51.129.145]) by OMTA02.westchester.pa.mail.comcast.net with comcast id RwEL1b00g38Mh0K3NwEPFQ; Wed, 11 Mar 2009 20:14:34 +0000 Message-ID: <49B829A9.6090300@wichorus.com> Date: Wed, 11 Mar 2009 13:14:17 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Tero Kivinen References: <18871.46432.577501.495334@fireball.kivinen.iki.fi> In-Reply-To: <18871.46432.577501.495334@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Yoav Nir , paul.hoffman@vpnc.org Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04) 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, 11 Mar 2009 20:14:00 -0000 Hi Tero, Tero Kivinen wrote: > Vijay Devarapalli writes: >> There at least three people who think that the IKE_AUTH response >> message should itself contain the REDIRECT payload. I went through the >> email exchange between Fan and Tero. There was no new information >> that came out of that discussion for me to make this change in the >> draft. >> >> Does any one else have an opinion? >> >> Otherwise I suggest the WG chairs to make a call on this. >> >> Both solutions, 1) sending a REDIRECT payload in the IKE_AUTH response >> 2) sending a NO_ADDITIONAL_SAS in the IKE_AUTH response followed by a >> REDIRECT message, would work. > > If you add text allowing REDIRECT with IKE_AUTH, then add also text > explaining how REDIRECT is used with other different extensions, > including EAP and multi auth. I.e. what happens if the server returns > REDIRECT before the first EAP exchange is finished, or what happens if > the server returns REDIRECT after the first EAP has succeeded, but > before the AUTH payload exchange after that, or what happens if server > returns REDIRECT even when the client wants to do another AUTH > negotiation etc. The one significant piece of information that the gateway has during the IKE_AUTH exchange, that it didn't have during the IKE_SA_INIT exchange, is the identity of the client. Some folks want to redirect the client based on whatever identity it presents. So if thats they case, the first IKE_AUTH response would be used for sending the REDIRECT payload. If the gateway wanted to redirect the client because of load conditions, it would have done it during the IKE_SA_INIT exchange itself. I don't expect the EAP exchange or the multiple auth exchange to trigger a redirect. We can make this explicit if needed. > I.e. if we take following example from the RFC4739: > > Initiator Responder > ----------- ----------- > 1. HDR, SA, KE, Ni --> > <-- 2. HDR, SA, KE, Nr, [CERTREQ], > N(MULTIPLE_AUTH_SUPPORTED) > 3. HDR, SK { IDi, [CERTREQ+], [IDr], > SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) } --> > <-- 4. HDR, SK { IDr, [CERT+], AUTH, > EAP(Request) } > 5. HDR, SK { EAP(Response) } --> > <-- 6. HDR, SK { EAP(Request) } > 7. HDR, SK { EAP(Response) } --> > <-- 8. HDR, SK { EAP(Success) } > 9. HDR, SK { AUTH, > N(ANOTHER_AUTH_FOLLOWS) } --> > <-- 10. HDR, SK { AUTH } > 11. HDR, SK { IDi } --> > <-- 12. HDR, SK { EAP(Request) } > 13. HDR, SK { EAP(Response) } --> > <-- 14. HDR, SK { EAP(Request) } > 15. HDR, SK { EAP(Response) } --> > <-- 16. HDR, SK { EAP(Success) } > 17. HDR, SK { AUTH } --> > <-- 18. HDR, SK { AUTH, SA, TSi, TSr } > > In which packets is the REDIRECT allowed. Is it only allowed in the > final 18th message? Is it also allowed in packet 10? Can it be sent > during any time of the EAP exachanges? I expect the REDIRECT payload to appear only in message 4. We can make this explicit if we decide to include the REDIRECT payload in the IKE_AUTH response. Vijay > > This is actually something that is bit unclear already in the RFC4306. > > For notification payloads belonging to the IPsec SA (IPCOMP_SUPPORTED, > ADDITIONAL_TS_POSSIBLE, USE_TRANSPORT_MODE, > ESP_TFC_PADDING_NOT_SUPPORTED, NON_FIRST_FRAGMENTS_ALSO), it is quite > logical that the payloads containing SA and TS* payloads are the ones > where they should be in, but for example ESP_TFC_PADDING_NOT_SUPPORTED > and NON_FIRST_FRAGMENTS_ALSO do not contain explicit text listing > where they should be. > > For others there are other defined places (i.e. > HTTP_CERT_LOOKUP_SUPPORTED should be in the payload containing > CERTREQ, REKEY_SA should be same packet as SA payload, COOKIE and > NAT_DETECTION_*_IP are used only in IKE_SA_INIT). > > For status notifications like INITIAL_CONTACT and SET_WINDOW_SIZE there > is no defined or logical place to send them, so most likely they can > be in any packet during IKE_AUTH exchange (or after that as separate > INFORMATIONAL exchange). > > The RFC4478 defines one more status notification i.e. AUTH_LIFETIME > and that is defined to be in last IKE_AUTH message, or as separate > INFORMATIONAL exchange. > > MOBIKE (RFC 4555) defines that the new status notifications which can > be in IKE_AUTH (MOBIKE_SUPPORTED and ADDITIONAL_IP*_ADDRESSES) are in > the IKE_AUTH message containing the SA payload. > > I assume that REDIRECT is going to be status notification, which means > that the IKE SA is created even when that is returned during IKE_AUTH, > and then the resulting IKE_AUTH still needs to be deleted with > separate INFORMATIONAL exchange containing delete payloads. From paul.hoffman@vpnc.org Wed Mar 11 13:20:17 2009 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 94C823A6B03 for ; Wed, 11 Mar 2009 13:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=-0.041, 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 AVj2+m1g5VwV for ; Wed, 11 Mar 2009 13:20:16 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0C5DF3A6358 for ; Wed, 11 Mar 2009 13:20:13 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2BKKkZF036502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2009 13:20:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <49B82819.9010901@wichorus.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727F1E99700@NOK-EUMSG-01.mgdnok.nokia.com> <49B82819.9010901@wichorus.com> Date: Wed, 11 Mar 2009 13:20:45 -0700 To: Vijay Devarapalli From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 11 Mar 2009 20:20:17 -0000 At 1:07 PM -0800 3/11/09, Vijay Devarapalli wrote: >There are environments where the client (e.g, Mobile IPv6 MN, 3GPP I-WLAN client) always discovers the gateways they need to attach to. They might get assigned different gateways based on what service they want to access, what their subscription profile is, etc.. In such environments, the PAD entries are created dynamically, but of course bound by the configuration on the mobile node. Of course. I was proposing that we do not add this mechanism to the list, but instead have it reflect the settings that were made by the other mechanisms. >I think the REDIRECT mechanism is of limited use if you can only redirect to another gateway for which the mobile node already has a PAD entry. Hmm. That was not clear to me from the document, but I could have missed it. What do others think about this statement? --Paul Hoffman, Director --VPN Consortium From latten@austin.ibm.com Wed Mar 11 15:15:20 2009 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 BCD363A68DB for ; Wed, 11 Mar 2009 15:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3quE4wbL8fAz for ; Wed, 11 Mar 2009 15:15:15 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id 3EA1C3A6872 for ; Wed, 11 Mar 2009 15:15:15 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n2BMCWdQ002873 for ; Wed, 11 Mar 2009 18:12:32 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2BMFo0G192788 for ; Wed, 11 Mar 2009 18:15:50 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2BMESiO002801 for ; Wed, 11 Mar 2009 18:14:28 -0400 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n2BMES4R002789; Wed, 11 Mar 2009 18:14:28 -0400 Received: from faith.austin.ibm.com (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id n2BMFnSU040018; Wed, 11 Mar 2009 17:15:49 -0500 Received: from faith.austin.ibm.com (localhost.localdomain [127.0.0.1]) by faith.austin.ibm.com (8.14.2/8.12.8) with ESMTP id n2BM6qNW010599; Wed, 11 Mar 2009 17:06:52 -0500 Received: (from jml@localhost) by faith.austin.ibm.com (8.14.2/8.14.2/Submit) id n2BM6qAf010598; Wed, 11 Mar 2009 17:06:52 -0500 X-Authentication-Warning: faith.austin.ibm.com: jml set sender to latten@austin.ibm.com using -f From: Joy Latten To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC73@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC73@il-ex01.ad.checkpoint.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 11 Mar 2009 17:06:51 -0500 Message-Id: <1236809211.3129.92.camel@faith.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Issue #15: Message ID reset to 0 after IKE SA rekey 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, 11 Mar 2009 22:15:20 -0000 On Tue, 2009-03-03 at 20:18 +0200, Yaron Sheffer wrote: > 2.2. Use of Sequence Numbers for Message ID > > The Message ID is a 32-bit quantity, which is zero for the IKE_SA_INIT > messages (including retries of the message due to responses such as > COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}), and incremented for > each subsequent exchange. > > Tero: > > Add text: > > The Message ID is reset to zero also after IKE SA rekey for the new > IKE SA. > That paragraph has another sentence "Rekeying an IKE SA resets the sequence numbers." Perhaps the above and this could be combined. Something like: Rekeying an IKE SA resets the sequence number counter to zero for the new IKE SA. regards, Joy From ynir@checkpoint.com Thu Mar 12 00:38:37 2009 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 EDF833A68C6 for ; Thu, 12 Mar 2009 00:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 aXhfoU7wy6Gs for ; Thu, 12 Mar 2009 00:38:37 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id BE5403A679C for ; Thu, 12 Mar 2009 00:38:36 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id C21022CC004; Thu, 12 Mar 2009 09:39:12 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id EFF1A2CC003; Thu, 12 Mar 2009 09:39:10 +0200 (IST) X-CheckPoint: {49B8BB3E-0-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n2C7dA16004357; Thu, 12 Mar 2009 09:39:10 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 12 Mar 2009 09:39:10 +0200 From: Yoav Nir To: Paul Hoffman , Vijay Devarapalli Date: Thu, 12 Mar 2009 09:39:50 +0200 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 Thread-Index: AcmihuSBTmbTyOp/RtK96wXfyeBIIwAXf9iA Message-ID: <9FB7C7CE79B84449B52622B506C78036133299F294@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727F1E99700@NOK-EUMSG-01.mgdnok.nokia.com> <49B82819.9010901@wichorus.com> In-Reply-To: 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: "ipsec@ietf.org" , "Pasi.Eronen@nokia.com" Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 12 Mar 2009 07:38:38 -0000 Paul Hoffman wrote:=20 >=20 > At 1:07 PM -0800 3/11/09, Vijay Devarapalli wrote: > >There are environments where the client (e.g, Mobile IPv6=20 > MN, 3GPP I-WLAN client) always discovers the gateways they=20 > need to attach to. They might get assigned different gateways=20 > based on what service they want to access, what their=20 > subscription profile is, etc.. In such environments, the PAD=20 > entries are created dynamically, but of course bound by the=20 > configuration on the mobile node. >=20 > Of course. I was proposing that we do not add this mechanism=20 > to the list, but instead have it reflect the settings that=20 > were made by the other mechanisms. >=20 > >I think the REDIRECT mechanism is of limited use if you can=20 > only redirect to another gateway for which the mobile node=20 > already has a PAD entry. >=20 > Hmm. That was not clear to me from the document, but I could=20 > have missed it. What do others think about this statement? Strongly disagree. The REDIRECT in the Initial exchange is unauthenticated= . The mobile node has not idea where this message has come from. I don't th= ink it makes any sense to alter the PAD based on an unauthenticated notific= ation. If we allow this, then REDIRECT says "go to this address on the Inte= rnet, and give them your user name and password". A fake REDIRECT could lea= d you to the attacker's gateway. You will accept any IDr it presents (becau= se you don't have a PAD entry to authenticate that gateway). That gateway c= an then mount a MitM attack with the real gateway. No. I would hesitate to change the PAD based on an authenticated message fr= om a trusted peer. I would never alter the PAD based on an unauthenticated = message. gw2 MUST be in the PAD (either the same entry or a different one)= Email secured by Check Point From Pasi.Eronen@nokia.com Thu Mar 12 03:21:26 2009 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 46C6A3A690A for ; Thu, 12 Mar 2009 03:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 fo8l1D8Nh73B for ; Thu, 12 Mar 2009 03:21:20 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id BA0C128C0ED for ; Thu, 12 Mar 2009 03:21:20 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2CAErXw005901; Thu, 12 Mar 2009 05:15:34 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 12:14:48 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 12:14:44 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 12:14:38 +0200 Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 12 Mar 2009 11:14:22 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Thu, 12 Mar 2009 11:14:22 +0100 From: To: Date: Thu, 12 Mar 2009 11:14:10 +0100 Thread-Topic: [IPsec] Issue #35: INVALID_SPI: does the SPI determine the protocol (ESP/AH)? Thread-Index: AcmieI8FCYZs5arcQpeBonsoAnHK0gAgb4LQ Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F1EF8C70@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC75@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727F1E99780@NOK-EUMSG-01.mgdnok.nokia.com> <1236796156.3129.85.camel@faith.austin.ibm.com> In-Reply-To: <1236796156.3129.85.camel@faith.austin.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2009 10:14:38.0932 (UTC) FILETIME=[5A203140:01C9A2FB] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #35: INVALID_SPI: does the SPI determine the protocol (ESP/AH)? 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, 12 Mar 2009 10:21:26 -0000 Joy Latten wrote: > > I think Tero's proposal about just noting this fact (i.e. not=20 > > changing how this work) would be OK and sufficient. >=20 > I could be missing something, but RFC4301, section 4.1 allows > implementations to use the SPI in conjunction with the IPsec protocol > for SA identification. So, if someone is in that latter case, wouldn't > they have a problem?=20 Well... depends on whether the recipient of the notification actually uses the SPI value for something (other than possibly debugging/logging). The "INVALID_SPI" notification basically means "I've rebooted, or our understanding of IPsec/IKEv2 state is otherwise screwed up". If this was an unprotected one-way notification, the recipient would it as a hint that things might be wrong, and initiates a liveness test for the IKE_SA. If it was a protected notification, it probably means an implementation bug somewhere, and a possible action would be to create a new IKE_SA (and new CHILD_SAs) from scratch. In neither case, the recipient really needs the SPI value for anything.. Best regards, Pasi= From kivinen@iki.fi Thu Mar 12 05:14:07 2009 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 2FE8B3A6A64 for ; Thu, 12 Mar 2009 05:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 s7RkbunwlWGk for ; Thu, 12 Mar 2009 05:14:06 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 0797D3A6A37 for ; Thu, 12 Mar 2009 05:14:04 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n2CCEZFv004947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2009 14:14:35 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n2CCEYpV008504; Thu, 12 Mar 2009 14:14: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: <18872.64682.15892.720908@fireball.kivinen.iki.fi> Date: Thu, 12 Mar 2009 14:14:34 +0200 From: Tero Kivinen To: Vijay Devarapalli In-Reply-To: <49B829A9.6090300@wichorus.com> References: <18871.46432.577501.495334@fireball.kivinen.iki.fi> <49B829A9.6090300@wichorus.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min Cc: IPsecme WG , Yoav Nir , paul.hoffman@vpnc.org Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04) 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, 12 Mar 2009 12:14:07 -0000 Vijay Devarapalli writes: > The one significant piece of information that the gateway has during the > IKE_AUTH exchange, that it didn't have during the IKE_SA_INIT exchange, > is the identity of the client. Some folks want to redirect the client > based on whatever identity it presents. So if thats they case, the first > IKE_AUTH response would be used for sending the REDIRECT payload. If the > gateway wanted to redirect the client because of load conditions, it > would have done it during the IKE_SA_INIT exchange itself. I don't > expect the EAP exchange or the multiple auth exchange to trigger a > redirect. We can make this explicit if needed. I tought someone wanted to do some kind of radius lookup to select where client is redirected to and in some cases client might not be sending the ID used for that in the ID payload but might use the EAP identity request/reply (even though RFC4306 3.16 says SHOULD NOT). If it will be enough to only see IDi to do redirect, meaning we can always restrict the REDIRECT to message 4, then it might be even acceptable to make that change. The main reason I was against having REDIRECTS in IKE_AUTHs is that there is so many locations where it can be and testing all possible combinations with all possible authentication methods and other extensions gets very complicated. -- kivinen@iki.fi From kivinen@iki.fi Thu Mar 12 05:24:01 2009 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 846AD3A6A7E for ; Thu, 12 Mar 2009 05:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 CetIonpan5B7 for ; Thu, 12 Mar 2009 05:23:59 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 632FE3A6A03 for ; Thu, 12 Mar 2009 05:23:59 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n2CCOZHF000423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2009 14:24:35 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n2CCOYDt012951; Thu, 12 Mar 2009 14:24: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: <18872.65282.101820.190035@fireball.kivinen.iki.fi> Date: Thu, 12 Mar 2009 14:24:34 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727F1E99700@NOK-EUMSG-01.mgdnok.nokia.com> <49B82819.9010901@wichorus.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 9 min Cc: ipsec@ietf.org, Vijay Devarapalli , Pasi.Eronen@nokia.com Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 12 Mar 2009 12:24:01 -0000 Paul Hoffman writes: > >I think the REDIRECT mechanism is of limited use if you can only > >redirect to another gateway for which the mobile node already has a > >PAD entry. > > Hmm. That was not clear to me from the document, but I could have > missed it. What do others think about this statement? I didn't get that from the draft. The current draft does not mention anything about PAD, and doing dynamic updates to PAD (or SPD) is something that must be explicitly mentioned if such things are supposed to happen, as they have lots of security implications (overwriting existing rules, to which location dynamic rules are added in the ordered PAD/SPD, what information is exactly put there). On the other hand I do not think the REDIRECT mechanism will be that much in limited use, even if the PAD entries must be configured. The mobile node requires PAD entry for the first gateway anyways, and if that PAD entry identifies the group of peers instead that one peer, and provides authentication data for each peer (for example say that they are authenticated using certificates signed by CA X). Depending on the configuration this can still be done quite easily. Example could be that PAD define ID must be *.sgw.example.com. and the peer must authenticate itself using certificate signed by CA X. Then first gateway can provide ID sgw1.sgw.example.com and it can redirect client to server, which then will use ID sgw2.sgw.example.com, and that will still match the same PAD entry. Both gateways will use certificates provided by the same CA so their authentication information is same. -- kivinen@iki.fi From welterk@us.ibm.com Thu Mar 12 09:45:06 2009 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 BA1E43A6BE7 for ; Thu, 12 Mar 2009 09:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.931 X-Spam-Level: X-Spam-Status: No, score=-3.931 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 0P6H0MJawQeZ for ; Thu, 12 Mar 2009 09:45:05 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id CD24D3A68A7 for ; Thu, 12 Mar 2009 09:45:05 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e37.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n2CGjJZo002751 for ; Thu, 12 Mar 2009 10:45:19 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2CGjdla223378 for ; Thu, 12 Mar 2009 10:45:40 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2CGjd7Q012875 for ; Thu, 12 Mar 2009 10:45:39 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n2CGjdRL012869 for ; Thu, 12 Mar 2009 10:45:39 -0600 To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Keith Welter X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 03/12/2009 09:45:35 AM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 03/12/2009 09:45:35 AM, Serialize complete at 03/12/2009 09:45:35 AM, S/MIME Sign failed at 03/12/2009 09:45:35 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 03/12/2009 10:45:38, Serialize complete at 03/12/2009 10:45:38 Message-ID: Date: Thu, 12 Mar 2009 09:45:38 -0700 Content-Type: multipart/alternative; boundary="=_alternative 005C109688257577_=" Subject: Re: [IPsec] Questions about RFC 4945 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, 12 Mar 2009 16:45:06 -0000 This is a multipart message in MIME format. --=_alternative 005C109688257577_= Content-Type: text/plain; charset="US-ASCII" Thanks Paul. I have a couple follow-up questions. First, I don't see where the following IP validation check described in section 3.1.1 for IKEv1 is specified for IKEv2: "In addition, implementations MUST be capable of verifying that the address contained in the ID is the same as the peer source address, contained in the outer most IP header." Though that particular check is not required for IKEv2, I assume it would be acceptable for an implementation to support such a check for IKEv2. Is that correct? Second, section 4.2.1 refers to section 3.2.3: "IKEv2 does not support Certificate Payload sizes over approximately 64K. See Section 3.2.3 for the problems this can cause." Does that mean section 3.2.3 applies to IKEv2? Paul Hoffman wrote on 03/09/2009 02:12:55 PM: > At 11:07 AM -0700 3/9/09, Keith Welter wrote: > >First, is this the right mailing on which to post questions about RFC 4945? > > > >Second, should RFC 4945 section 4 (Use of Certificates in RFC 4301 and IKEv2) be > considered a supplement to section 3 (Use of Certificates in RFC 2401 and > IKEv1/ISAKMP) or should section 3 and section 4 be considered to be completely independent? > > Completely independent. > > --Paul Hoffman, Director > --VPN Consortium Keith Welter IBM Enterprise Networking Solutions 1-415-545-2694 (T/L: 473-2694) --=_alternative 005C109688257577_= Content-Type: text/html; charset="US-ASCII"
Thanks Paul.  I have a couple follow-up questions.  

First, I don't see where the following IP validation check described in section 3.1.1 for IKEv1 is specified for IKEv2:
"In addition, implementations MUST be capable of verifying that the address contained in the ID is the same as the peer source address, contained in the outer most IP header."

Though that particular check is not required for IKEv2, I assume it would be acceptable for an implementation to support such a check for IKEv2.  Is that correct?

Second, section 4.2.1 refers to section 3.2.3:
"IKEv2 does not support Certificate Payload sizes over approximately 64K.  See Section 3.2.3 for the problems this can cause."

Does that mean section 3.2.3 applies to IKEv2?

Paul Hoffman <paul.hoffman@vpnc.org> wrote on 03/09/2009 02:12:55 PM:

> At 11:07 AM -0700 3/9/09, Keith Welter wrote:
> >First, is this the right mailing on which to post questions about RFC 4945?
> >
> >Second, should RFC 4945 section 4 (Use of Certificates in RFC 4301 and IKEv2) be
> considered a supplement to section 3 (Use of Certificates in RFC 2401 and
> IKEv1/ISAKMP) or should section 3 and section 4 be considered to be completely independent?
>
> Completely independent.
>
> --Paul Hoffman, Director
> --VPN Consortium
Keith Welter
IBM Enterprise Networking Solutions
1-415-545-2694 (T/L: 473-2694)
 --=_alternative 005C109688257577_=-- From paul.hoffman@vpnc.org Thu Mar 12 09:56:23 2009 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 64D0228C1E5 for ; Thu, 12 Mar 2009 09:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=-0.040, 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 vC784C+oOVky for ; Thu, 12 Mar 2009 09:56:19 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D30CF3A69B5 for ; Thu, 12 Mar 2009 09:56:18 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2CGurX3001565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2009 09:56:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 12 Mar 2009 09:56:52 -0700 To: Keith Welter , ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Questions about RFC 4945 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, 12 Mar 2009 16:56:23 -0000 At 9:45 AM -0700 3/12/09, Keith Welter wrote: >Thanks Paul. I have a couple follow-up questions. > >First, I don't see where the following IP validation check described in section 3.1.1 for IKEv1 is specified for IKEv2: >"In addition, implementations MUST be capable of verifying that the address contained in the ID is the same as the peer source address, contained in the outer most IP header." > >Though that particular check is not required for IKEv2, I assume it would be acceptable for an implementation to support such a check for IKEv2. Is that correct? Of course. Implementations can add as many checks as they want. >Second, section 4.2.1 refers to section 3.2.3: >"IKEv2 does not support Certificate Payload sizes over approximately 64K. See Section 3.2.3 for the problems this can cause." > >Does that mean section 3.2.3 applies to IKEv2? Yes, by reference. --Paul Hoffman, Director --VPN Consortium From smoonen@us.ibm.com Thu Mar 12 11:51:38 2009 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 A264B3A69A6 for ; Thu, 12 Mar 2009 11:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 nbrSmiAuAFU2 for ; Thu, 12 Mar 2009 11:51:37 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id 8AAE13A6962 for ; Thu, 12 Mar 2009 11:51:37 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n2CIlw5n021703 for ; Thu, 12 Mar 2009 12:47:58 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2CIqC6v192868 for ; Thu, 12 Mar 2009 12:52:12 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2CIqBgE023936 for ; Thu, 12 Mar 2009 12:52:12 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n2CIqAv6023862 for ; Thu, 12 Mar 2009 12:52:10 -0600 To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 640B62CD:83A06777-85257577:00646F6F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 03/12/2009 02:49:43 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 03/12/2009 02:49:43 PM, Serialize complete at 03/12/2009 02:49:43 PM, S/MIME Sign failed at 03/12/2009 02:49:43 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 03/12/2009 12:52:09, Serialize complete at 03/12/2009 12:52:09 Message-ID: Date: Thu, 12 Mar 2009 14:52:09 -0400 Content-Type: multipart/alternative; boundary="=_alternative 00676DBA85257577_=" Subject: [IPsec] minor comment on ikev2bis 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: Thu, 12 Mar 2009 18:51:38 -0000 This is a multipart message in MIME format. --=_alternative 00676DBA85257577_= Content-Type: text/plain; charset="US-ASCII" Section 1.3.2 indicates that the KEi payload MUST be included, but the diagram puts it in brackets. Additionally, in section 1.3.2 the responder diagram shows KEr in brackets. But KEr is no more optional than SA and Nr; i.e., it must be present on success, and will be absent on any failure (such as INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, etc.). Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen --=_alternative 00676DBA85257577_= Content-Type: text/html; charset="US-ASCII"
Section 1.3.2 indicates that the KEi payload MUST be included, but the diagram puts it in brackets.

Additionally, in section 1.3.2 the responder diagram shows KEr in brackets.  But KEr is no more optional than SA and Nr; i.e., it must be present on success, and will be absent on any failure (such as INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, etc.).


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen --=_alternative 00676DBA85257577_=-- From yaronf@checkpoint.com Thu Mar 12 13:06:46 2009 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 E60483A6A8A for ; Thu, 12 Mar 2009 13:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.817 X-Spam-Level: X-Spam-Status: No, score=-2.817 tagged_above=-999 required=5 tests=[AWL=-0.218, 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 6V4hGGfMavEc for ; Thu, 12 Mar 2009 13:06:46 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 6A44E3A67EA for ; Thu, 12 Mar 2009 13:06:45 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 3BCE12CC002; Thu, 12 Mar 2009 22:07:22 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 0D0B12CC001; Thu, 12 Mar 2009 22:07:21 +0200 (IST) X-CheckPoint: {49B96A8F-0-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n2CK7K16021535; Thu, 12 Mar 2009 22:07:20 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 12 Mar 2009 22:07:20 +0200 From: Yaron Sheffer To: Tero Kivinen , Vijay Devarapalli Date: Thu, 12 Mar 2009 22:07:18 +0200 Thread-Topic: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04) Thread-Index: AcmjDCfdCgeYkOmTSzOcpv4JBlWEyAAQRPCw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F616@il-ex01.ad.checkpoint.com> References: <18871.46432.577501.495334@fireball.kivinen.iki.fi> <49B829A9.6090300@wichorus.com> <18872.64682.15892.720908@fireball.kivinen.iki.fi> In-Reply-To: <18872.64682.15892.720908@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A6_01C9A35E.E8C15F10" MIME-Version: 1.0 Cc: IPsecme WG , Yoav Nir , "paul.hoffman@vpnc.org" Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04) 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, 12 Mar 2009 20:06:47 -0000 ------=_NextPart_000_00A6_01C9A35E.E8C15F10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We should not do the redirect based on an asserted, unautheticated identity. Going back to Tero's previous message on this thread, I think we should allow redirect both in message 10 and 18 (i.e. following both EAP rounds, and where the EAP state machine is "idle"). The gateway probably needs the AAA server to tell it where to redirect to, anyway. In message 10 the gateway still doesn't know that the client wants to perform secondary authentication, but I propose to ignore this issue for simplicity. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Tero Kivinen > Sent: Thursday, March 12, 2009 14:15 > To: Vijay Devarapalli > Cc: IPsecme WG; Yoav Nir; paul.hoffman@vpnc.org > Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call: > draft-ietf-ipsecme-ikev2-redirect-04) > > Vijay Devarapalli writes: > > The one significant piece of information that the gateway has during the > > IKE_AUTH exchange, that it didn't have during the IKE_SA_INIT exchange, > > is the identity of the client. Some folks want to redirect the client > > based on whatever identity it presents. So if thats they case, the first > > IKE_AUTH response would be used for sending the REDIRECT payload. If the > > gateway wanted to redirect the client because of load conditions, it > > would have done it during the IKE_SA_INIT exchange itself. I don't > > expect the EAP exchange or the multiple auth exchange to trigger a > > redirect. We can make this explicit if needed. > > I tought someone wanted to do some kind of radius lookup to select > where client is redirected to and in some cases client might not be > sending the ID used for that in the ID payload but might use the EAP > identity request/reply (even though RFC4306 3.16 says SHOULD NOT). > > If it will be enough to only see IDi to do redirect, meaning we can > always restrict the REDIRECT to message 4, then it might be even > acceptable to make that change. The main reason I was against having > REDIRECTS in IKE_AUTHs is that there is so many locations where it can > be and testing all possible combinations with all possible > authentication methods and other extensions gets very complicated. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_00A6_01C9A35E.E8C15F10 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDMxMjIwMDcxOFowIwYJKoZIhvcNAQkEMRYEFAawDorZH2qI h8lnT6vZMAn5oNvwMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA SEixD5eTN1VnToxboOPjH9KKDKjZsgCvehvNFNYMMxFNSIUP2wxcIJQt+cwX1IxW9Idw+wcraECQ rZKWdQjIYBU5oi7n49SeWfONZzWF2bGkLbaObX8Ubre5nc4MLGt2PzBte6Xe5XUKFeZ0D5ZzOsTh exdPkXFoaO6Awzz6Vd/1thwovTa0XAZq7ux6S651LXD+zsWgNkt+aSS6jR5wy3HFQTh8dUPAeX0u mDYlKseFTcBd9v4aluOkg6wuektIB0yrmnCt8wEBNzO477UGoiiN+U2hIQ1CL0DjOsX+BZ5g/ZUA B6+UdYjMFft+pmxyu2885PpLcdyaiwjKLoC5LgAAAAAAAA== ------=_NextPart_000_00A6_01C9A35E.E8C15F10-- From yaronf@checkpoint.com Thu Mar 12 13:40:46 2009 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 8FF9628C1D6 for ; Thu, 12 Mar 2009 13:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=-0.211, 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 I0w0-RhCQgLZ for ; Thu, 12 Mar 2009 13:40:45 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 239BE3A6A4A for ; Thu, 12 Mar 2009 13:40:44 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 280C12CC003; Thu, 12 Mar 2009 22:41:21 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 399EE2CC002; Thu, 12 Mar 2009 22:41:19 +0200 (IST) X-CheckPoint: {49B97284-2-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n2CKfI16028454; Thu, 12 Mar 2009 22:41:18 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 12 Mar 2009 22:41:18 +0200 From: Yaron Sheffer To: Tero Kivinen Date: Thu, 12 Mar 2009 22:41:16 +0200 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 Thread-Index: AcmguHSeSN2iDKmgTHmp1LkRffOX/wCmB/Sg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F61D@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EFC5@il-ex01.ad.checkpoint.com> <18865.10880.221267.329987@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EFF2@il-ex01.ad.checkpoint.com> <18869.5454.101452.948354@fireball.kivinen.iki.fi> In-Reply-To: <18869.5454.101452.948354@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00B0_01C9A363.A7370360" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "Pasi.Eronen@nokia.com" , "rfgraveman@gmail.com" , Vijay Devarapalli Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 12 Mar 2009 20:40:46 -0000 ------=_NextPart_000_00B0_01C9A363.A7370360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tero, Apologies for my late reply. My interpretation of redirect is that Gateway A is telling Client C: "go talk to Gateway B instead of me. I am overloaded, or going down for maintenance, and Gateway B can do the same things that I can do." Which in particular means that routing was configured so that GW B can *really* act like GW A. A and B are not "the same gateway", they do not share state, so MOBIKE cannot be used. The exact same thing applies to the gateway-to-gateway situation. Suppose Gateway C initiated an IKE SA with gateway A. Two hours later GW C goes into maintenance, so it asks GW A to redirect into Gateway D. GW A cannot just initiate a connection to D, because it doesn't know that it needs to until told by GW C. And it doesn't matter who initiated the SA in the first place. Yes, there is some routing/tunneling magic going on "behind" the gateways, but why should we rely on it to initiate the IKE redirection, when we have the mechanism defined in the current draft? Thanks, Yaron > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Monday, March 09, 2009 15:11 > To: Yaron Sheffer > Cc: Vijay Devarapalli; Pasi.Eronen@nokia.com; ipsec@ietf.org; > rfgraveman@gmail.com > Subject: RE: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 > > Yaron Sheffer writes: > > I am thinking of symmetric IKE peers (gateways, or endpoints using > > transport mode ESP; no EAP, rarely any NAT). Is there any reason why > > the current draft cannot support this case in a symmetric manner? > > Why do you need any protocol for that. Why does not normal IKEv2 be > enough for that. > > I.e. if node A wants the node B to move to use some other location, it > can simply connect to node B using that new location, and remove the > old IKE SA. > > I.e. if scenario is really symmetric, there is no need to have any > IKEv2 redirect protocol at all, everything can be done by the node by > directly connecting using new location. > > It is quite hard to explain this thing as I have no idea what kind of > scenario you are talking about. Can you give real example, what the > nodes are and why do they want to redirect other end. > > MOBIKE is not restricted to the VPN client <-> VPN server situation, > but is limited that node must stay same. I.e. it is moving between > multiple addresses of node A and moving between multiple address of > node B. It cannot ask node B to move from node A to node C. > > But if node A wants node B to use node C instead of node A, it can > simply inform node C to make connection to B and delete its own IKE > SA. It can also do this by just changing the back end routing or > similar, so that return packets go to node C instead of node A and > then node C will initiate connection to node B immediately when first > packet arrives (if the situation is really symmetric). > > If we are talking about client and server situations where server > wants to redirect client to some other server, then situation is no > longer symmetric. > -- > kivinen@iki.fi > > Scanned by Check Point Total Security Gateway. > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_00B0_01C9A363.A7370360 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDMxMjIwNDExNVowIwYJKoZIhvcNAQkEMRYEFHbGhZCsSnn7 A8AvbDbo/aWad9I6MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA rXRUc0MYE1/wcRPOdzwSONfJgKeQzKFk+l9C+Hx6efXqd4//TspgY5X7RxvFIXxRS35Z3Z0Lb1P8 Bd70pryBlbbbTYVD86asIOOnkI13wWflK4DOyD8Qn8ll/4fc6UwWPxuS+ewofdM9opPMILIrrARP 1ZPBQLXEqX0Jel669uR8G1te9hVMd6BEzVVZp/2vWJ5N1SpX+8oOB4elVIccChNYIabCkulMqCjw 7ZKQVkwPC5L5L94j31mL2stQ5JwtuW8c+U62VpwxlkZegQGmmBbOkz6jUqKhWcMPmW9ENcyhjl8Z SKi87zHUTXJXdXMrDW7IJImo5qEctMNwZDAXtQAAAAAAAA== ------=_NextPart_000_00B0_01C9A363.A7370360-- From paul.hoffman@vpnc.org Thu Mar 12 15:03:54 2009 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 861223A6A1D for ; Thu, 12 Mar 2009 15:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.039, 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 rC2cIfxqVnfT for ; Thu, 12 Mar 2009 15:03:53 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 73C9A3A68F6 for ; Thu, 12 Mar 2009 15:03:53 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2CM4STP017678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2009 15:04:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 12 Mar 2009 15:04:24 -0700 To: Scott C Moonen , ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] minor comment on ikev2bis 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: Thu, 12 Mar 2009 22:03:54 -0000 At 2:52 PM -0400 3/12/09, Scott C Moonen wrote: >Section 1.3.2 indicates that the KEi payload MUST be included, but the diagram puts it in brackets. > >Additionally, in section 1.3.2 the responder diagram shows KEr in brackets. But KEr is no more optional than SA and Nr; i.e., it must be present on success, and will be absent on any failure (such as INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, etc.). This is an extension to now-closed issue #50. Good call. I will remove the brackets from around the KEs in the diagrams. --Paul Hoffman, Director --VPN Consortium From kivinen@iki.fi Fri Mar 13 05:06:12 2009 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 6EB783A6A11 for ; Fri, 13 Mar 2009 05:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 fyIQRXd4VvxE for ; Fri, 13 Mar 2009 05:06:06 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 28C7628C0DB for ; Fri, 13 Mar 2009 05:06:05 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n2DC6U2p004678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Mar 2009 14:06:30 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n2DC6Sus008939; Fri, 13 Mar 2009 14:06: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: <18874.19524.306321.904579@fireball.kivinen.iki.fi> Date: Fri, 13 Mar 2009 14:06:28 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F61D@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EFC5@il-ex01.ad.checkpoint.com> <18865.10880.221267.329987@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EFF2@il-ex01.ad.checkpoint.com> <18869.5454.101452.948354@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F61D@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 10 min Cc: "ipsec@ietf.org" , "Pasi.Eronen@nokia.com" , "rfgraveman@gmail.com" , Vijay Devarapalli Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 13 Mar 2009 12:06:12 -0000 Yaron Sheffer writes: > The exact same thing applies to the gateway-to-gateway situation. Suppose > Gateway C initiated an IKE SA with gateway A. Two hours later GW C goes into > maintenance, so it asks GW A to redirect into Gateway D. GW A cannot just > initiate a connection to D, because it doesn't know that it needs to until > told by GW C. And it doesn't matter who initiated the SA in the first place. When C goes to the maintenance, it will also change routing so that packets which used to come to him, will go to D. Immediately when first such packet gets to D, the D will initiate connection to A, so C can simply change the routing, and then delete all IKE SAs. > Yes, there is some routing/tunneling magic going on "behind" the gateways, > but why should we rely on it to initiate the IKE redirection, when we have > the mechanism defined in the current draft? Mostly because redirections gets very complicated if both ends can move at will... For example what happens if the gateway A is rebooted, while C is still down. Now C will not reply with redirect to D, thus we still need to rely on some other external mechanism to redirect stuff from C to D, i.e. most likely both of them are configured in the configuration, so A will know that it can connect either C or D. When we were writing MOBIKE, we noticed that things gets very complicated very quickly if such scenarios are allowed, and in that case you cannot really expect the systems to just work, you still need to write new document profiling how nodes should be configured and used in such cases. If we are going to need such profile anyways to get usable protocol, we can write protocol extension at the same time which profiles redirect to be used in gw-gw scenarios and also extends and defines how it should be used in that case. We have way too many protocols already where the actual protocol document does not provide interoperability. The documents are so wide open, that nobody implements all the optional things (or not even all the mandatory to implement things), thus you cannot just take two implementations and assume they work together on your specific scenario. In those cases you need to write profile that tells what features are required, and then you might get interoperability (provided you will find any implementations fulfilling those requirements). My proposal was to say that we do not define that usage in this document, but it is not explicitly forbidden either, so we assume that if such usage is needed, new document extending this one will be written. -- kivinen@iki.fi From latten@austin.ibm.com Fri Mar 13 13:11:13 2009 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 E33D33A687E for ; Fri, 13 Mar 2009 13:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.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 iwiejeSrUU2E for ; Fri, 13 Mar 2009 13:11:13 -0700 (PDT) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by core3.amsl.com (Postfix) with ESMTP id 286D13A682D for ; Fri, 13 Mar 2009 13:11:12 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e39.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n2DK94EJ005983 for ; Fri, 13 Mar 2009 14:09:04 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2DKBoLg222774 for ; Fri, 13 Mar 2009 14:11:50 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2DKBoWq005640 for ; Fri, 13 Mar 2009 14:11:50 -0600 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n2DKBojG005634; Fri, 13 Mar 2009 14:11:50 -0600 Received: from faith.austin.ibm.com (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id n2DKBnfK045482; Fri, 13 Mar 2009 15:11:49 -0500 Received: from faith.austin.ibm.com (localhost.localdomain [127.0.0.1]) by faith.austin.ibm.com (8.14.2/8.12.8) with ESMTP id n2DK2jBn026597; Fri, 13 Mar 2009 15:02:45 -0500 Received: (from jml@localhost) by faith.austin.ibm.com (8.14.2/8.14.2/Submit) id n2DK2iSY026596; Fri, 13 Mar 2009 15:02:44 -0500 X-Authentication-Warning: faith.austin.ibm.com: jml set sender to latten@austin.ibm.com using -f From: Joy Latten To: Pasi.Eronen@nokia.com In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F1EF8C70@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC75@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727F1E99780@NOK-EUMSG-01.mgdnok.nokia.com> <1236796156.3129.85.camel@faith.austin.ibm.com> <808FD6E27AD4884E94820BC333B2DB7727F1EF8C70@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 13 Mar 2009 15:02:43 -0500 Message-Id: <1236974564.3129.97.camel@faith.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #35: INVALID_SPI: does the SPI determine the protocol (ESP/AH)? 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, 13 Mar 2009 20:11:14 -0000 On Thu, 2009-03-12 at 11:14 +0100, Pasi.Eronen@nokia.com wrote: > Joy Latten wrote: > > > > I think Tero's proposal about just noting this fact (i.e. not > > > changing how this work) would be OK and sufficient. > > > > I could be missing something, but RFC4301, section 4.1 allows > > implementations to use the SPI in conjunction with the IPsec protocol > > for SA identification. So, if someone is in that latter case, wouldn't > > they have a problem? > > Well... depends on whether the recipient of the notification actually > uses the SPI value for something (other than possibly debugging/logging). > > The "INVALID_SPI" notification basically means "I've rebooted, or our > understanding of IPsec/IKEv2 state is otherwise screwed up". If this > was an unprotected one-way notification, the recipient would it as a > hint that things might be wrong, and initiates a liveness test for the > IKE_SA. If it was a protected notification, it probably means an > implementation bug somewhere, and a possible action would be to create > a new IKE_SA (and new CHILD_SAs) from scratch. In neither case, the > recipient really needs the SPI value for anything.. > Ah, ok, that is true. That makes sense. Thanks for explaining. regards, Joy From vijay@wichorus.com Mon Mar 16 15:10:58 2009 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 C963C3A6954 for ; Mon, 16 Mar 2009 15:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-1.014, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] 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 awcNJopXSN9v for ; Mon, 16 Mar 2009 15:10:58 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id D2DA83A6AFA for ; Mon, 16 Mar 2009 15:10:57 -0700 (PDT) Received: from 99.51.129.145 ([99.51.129.145]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Mon, 16 Mar 2009 22:11:39 +0000 Received: from vijay-ipv6-desktop by owa.mse15.exchange.ms; 16 Mar 2009 15:11:39 -0700 From: Vijay Devarapalli To: Yaron Sheffer , Tero Kivinen In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F616@il-ex01.ad.checkpoint.com> References: <18871.46432.577501.495334@fireball.kivinen.iki.fi> <49B829A9.6090300@wichorus.com> <18872.64682.15892.720908@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F616@il-ex01.ad.checkpoint.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 16 Mar 2009 15:11:38 -0700 Message-Id: <1237241498.5668.21.camel@vijay-ipv6-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 Cc: IPsecme WG Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) 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, 16 Mar 2009 22:10:58 -0000 Hi Yaron, Tero, We don't really have a protocol extension (EAP, RADIUS or Diameter) for the AAA server to tell the IKEv2 gateway to redirect the client to another gateway. In addition, if there is an EAP exchange, the true identity of the client is not revealed to the gateway. So I am not sure on what basis the gateway would redirect the client in message #10 and #18 in Tero's email. http://www.ietf.org/mail-archive/web/ipsec/current/msg04025.html My proposal is to limit the REDIRECT payload to appear in message #4 (in the first IKE_AUTH response), based on the identity presented by the client. And leave EAP scenarios out of scope for this document. If someone wants the AAA server to redirect the client based on the EAP exchange, a separate document could be written. And this document can specify that the REDIRECT message can be sent in message 10. Does this sound good? Vijay On Thu, 2009-03-12 at 16:07 -0400, Yaron Sheffer wrote: > We should not do the redirect based on an asserted, unautheticated identity. > Going back to Tero's previous message on this thread, I think we should > allow redirect both in message 10 and 18 (i.e. following both EAP rounds, > and where the EAP state machine is "idle"). The gateway probably needs the > AAA server to tell it where to redirect to, anyway. > > In message 10 the gateway still doesn't know that the client wants to > perform secondary authentication, but I propose to ignore this issue for > simplicity. > > Thanks, > Yaron > > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > > Tero Kivinen > > Sent: Thursday, March 12, 2009 14:15 > > To: Vijay Devarapalli > > Cc: IPsecme WG; Yoav Nir; paul.hoffman@vpnc.org > > Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call: > > draft-ietf-ipsecme-ikev2-redirect-04) > > > > Vijay Devarapalli writes: > > > The one significant piece of information that the gateway has during the > > > IKE_AUTH exchange, that it didn't have during the IKE_SA_INIT exchange, > > > is the identity of the client. Some folks want to redirect the client > > > based on whatever identity it presents. So if thats they case, the first > > > IKE_AUTH response would be used for sending the REDIRECT payload. If the > > > gateway wanted to redirect the client because of load conditions, it > > > would have done it during the IKE_SA_INIT exchange itself. I don't > > > expect the EAP exchange or the multiple auth exchange to trigger a > > > redirect. We can make this explicit if needed. > > > > I tought someone wanted to do some kind of radius lookup to select > > where client is redirected to and in some cases client might not be > > sending the ID used for that in the ID payload but might use the EAP > > identity request/reply (even though RFC4306 3.16 says SHOULD NOT). > > > > If it will be enough to only see IDi to do redirect, meaning we can > > always restrict the REDIRECT to message 4, then it might be even > > acceptable to make that change. The main reason I was against having > > REDIRECTS in IKE_AUTHs is that there is so many locations where it can > > be and testing all possible combinations with all possible > > authentication methods and other extensions gets very complicated. > > -- > > kivinen@iki.fi > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > Scanned by Check Point Total Security Gateway. > > > > Scanned by Check Point Total Security Gateway. From yaronf@checkpoint.com Mon Mar 16 15:40:49 2009 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 ACC6D3A6902 for ; Mon, 16 Mar 2009 15:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=-0.190, 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 0YxMG+3n3uZ9 for ; Mon, 16 Mar 2009 15:40:48 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id C496E3A6829 for ; Mon, 16 Mar 2009 15:40:47 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 48DC12CC002; Tue, 17 Mar 2009 00:41:29 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id C8BE52CC001; Tue, 17 Mar 2009 00:40:33 +0200 (IST) X-CheckPoint: {49BED42D-0-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n2GMeX16018291; Tue, 17 Mar 2009 00:40:33 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 17 Mar 2009 00:40:32 +0200 From: Yaron Sheffer To: Vijay Devarapalli , Tero Kivinen Date: Tue, 17 Mar 2009 00:40:30 +0200 Thread-Topic: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) Thread-Index: AcmmhDCmGzbHMm/VS4q5SumuQX7K0wAAzbMw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F932@il-ex01.ad.checkpoint.com> References: <18871.46432.577501.495334@fireball.kivinen.iki.fi> <49B829A9.6090300@wichorus.com> <18872.64682.15892.720908@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F616@il-ex01.ad.checkpoint.com> <1237241498.5668.21.camel@vijay-ipv6-desktop> In-Reply-To: <1237241498.5668.21.camel@vijay-ipv6-desktop> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00D6_01C9A698.F9027F20" MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) 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, 16 Mar 2009 22:40:49 -0000 ------=_NextPart_000_00D6_01C9A698.F9027F20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Vijay, I don't have the details at hand, but in 3GPP land it is common for the client to send all sorts of temporary identities, and for the AAA server to respond to the Packet Data Gateway (that's our gateway) with the client's "true" identity (IMSI, MSISDN, whatever). Such permanent identity could serve as the basis for a redirect decision. Do we have people on the list familiar with these specs? Thanks, Yaron > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Tuesday, March 17, 2009 0:12 > To: Yaron Sheffer; Tero Kivinen > Cc: IPsecme WG > Subject: RE: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft- > ietf-ipsecme-ikev2-redirect-04) > > Hi Yaron, Tero, > > We don't really have a protocol extension (EAP, RADIUS or Diameter) for > the AAA server to tell the IKEv2 gateway to redirect the client to > another gateway. > > In addition, if there is an EAP exchange, the true identity of the > client is not revealed to the gateway. > > So I am not sure on what basis the gateway would redirect the client in > message #10 and #18 in Tero's email. > http://www.ietf.org/mail-archive/web/ipsec/current/msg04025.html > > My proposal is to limit the REDIRECT payload to appear in message #4 (in > the first IKE_AUTH response), based on the identity presented by the > client. And leave EAP scenarios out of scope for this document. If > someone wants the AAA server to redirect the client based on the EAP > exchange, a separate document could be written. And this document can > specify that the REDIRECT message can be sent in message 10. > > Does this sound good? > > Vijay > > On Thu, 2009-03-12 at 16:07 -0400, Yaron Sheffer wrote: > > We should not do the redirect based on an asserted, unautheticated > identity. > > Going back to Tero's previous message on this thread, I think we should > > allow redirect both in message 10 and 18 (i.e. following both EAP > rounds, > > and where the EAP state machine is "idle"). The gateway probably needs > the > > AAA server to tell it where to redirect to, anyway. > > > > In message 10 the gateway still doesn't know that the client wants to > > perform secondary authentication, but I propose to ignore this issue for > > simplicity. > > > > Thanks, > > Yaron > > > > > -----Original Message----- > > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of > > > Tero Kivinen > > > Sent: Thursday, March 12, 2009 14:15 > > > To: Vijay Devarapalli > > > Cc: IPsecme WG; Yoav Nir; paul.hoffman@vpnc.org > > > Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call: > > > draft-ietf-ipsecme-ikev2-redirect-04) > > > > > > Vijay Devarapalli writes: > > > > The one significant piece of information that the gateway has during > the > > > > IKE_AUTH exchange, that it didn't have during the IKE_SA_INIT > exchange, > > > > is the identity of the client. Some folks want to redirect the > client > > > > based on whatever identity it presents. So if thats they case, the > first > > > > IKE_AUTH response would be used for sending the REDIRECT payload. If > the > > > > gateway wanted to redirect the client because of load conditions, it > > > > would have done it during the IKE_SA_INIT exchange itself. I don't > > > > expect the EAP exchange or the multiple auth exchange to trigger a > > > > redirect. We can make this explicit if needed. > > > > > > I tought someone wanted to do some kind of radius lookup to select > > > where client is redirected to and in some cases client might not be > > > sending the ID used for that in the ID payload but might use the EAP > > > identity request/reply (even though RFC4306 3.16 says SHOULD NOT). > > > > > > If it will be enough to only see IDi to do redirect, meaning we can > > > always restrict the REDIRECT to message 4, then it might be even > > > acceptable to make that change. The main reason I was against having > > > REDIRECTS in IKE_AUTHs is that there is so many locations where it can > > > be and testing all possible combinations with all possible > > > authentication methods and other extensions gets very complicated. > > > -- > > > kivinen@iki.fi > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > Scanned by Check Point Total Security Gateway. > > > > > > Scanned by Check Point Total Security Gateway. > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_00D6_01C9A698.F9027F20 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDMxNjIyNDAyOVowIwYJKoZIhvcNAQkEMRYEFP4WtldAS9X5 /AGZuwDLtZfCrelPMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA ZLAgAIjzDK50LYN16/3A6o05l4IZAvHl/Hn+MreUrSGjnLqom4QxFNMV45ncq/M8Yo88aLdURvO9 MDovecCRKvx87MgGqcL1yAFUJAP7c/8e7Y5sXWWCjyV0bAzNbGEbkAACn7a8VNRrrXZKaMijyyes NNvz5HXjukg6++IXQxizb8VyneQQ+lpKV97b3TEOXm9usyw9V/REhQjZ/SG40uUxDnMTo//zgSpB pnzzm1/dhSa44yhpV8T5VeIBBPEnuIYXFsT8iy8VP4goayo+mHNEKokploqVUvVkkJ2CB/VmX5dr sK3phqemwDvKvR9D9vX6GrZTpFWS53577pHFxAAAAAAAAA== ------=_NextPart_000_00D6_01C9A698.F9027F20-- From vijay@wichorus.com Mon Mar 16 15:55:40 2009 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 ED2BE3A6830 for ; Mon, 16 Mar 2009 15:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 BD8HbhevvCaJ for ; Mon, 16 Mar 2009 15:55:39 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id 98A843A67AA for ; Mon, 16 Mar 2009 15:55:39 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA11.westchester.pa.mail.comcast.net with comcast id ToxM1b0040Fqzac5BywN13; Mon, 16 Mar 2009 22:56:22 +0000 Received: from [10.166.254.108] ([99.51.129.145]) by OMTA08.westchester.pa.mail.comcast.net with comcast id Tyxz1b00a38Mh0K3Uyy7Ez; Mon, 16 Mar 2009 22:58:19 +0000 Message-ID: <49BED8F9.5000403@wichorus.com> Date: Mon, 16 Mar 2009 15:55:53 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Yaron Sheffer References: <18871.46432.577501.495334@fireball.kivinen.iki.fi> <49B829A9.6090300@wichorus.com> <18872.64682.15892.720908@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F616@il-ex01.ad.checkpoint.com> <1237241498.5668.21.camel@vijay-ipv6-desktop> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F932@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F932@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Tero Kivinen Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) 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, 16 Mar 2009 22:55:41 -0000 Yaron Sheffer wrote: > Hi Vijay, > > I don't have the details at hand, but in 3GPP land it is common for the > client to send all sorts of temporary identities, and for the AAA server to > respond to the Packet Data Gateway (that's our gateway) with the client's > "true" identity (IMSI, MSISDN, whatever). Such permanent identity could > serve as the basis for a redirect decision. Do we have people on the list > familiar with these specs? I am aware of these specs. The last EAP message with "Success" from the AAA server to the gateway, has the real identity of the client as a RADIUS attribute (for example). But we don't have a reference for this in the IETF, since RFC 4306 says that there shouldn't be an EAP Identity Request/Response exchange. In RFC 4877, we did mention that the Mobile IPv6 home agent MUST acquire the true identity of the mobile node when EAP is used, but left the actual mechanism out of scope. Section 8 of RFC 4877 says When EAP is used, the identity presented by the mobile node in the IDi field may not be the actual identity of the mobile node. It could be set to an identity that is used only for Authentication, Authorization, and Accounting (AAA) routing purposes and selecting the right EAP method. It is possible that the actual identity is carried inside EAP, invisible to the home agent. While IKEv2 does not allow an EAP Identity Request/Response message exchange, EAP methods may exchange identities within themselves. In this case, the home agent MUST acquire the mobile node's identity from the corresponding AAA server. How the home agent acquires the mobile node's identity is out of scope for this document. One option would to be adapt the above text to say that if the client had presented a temporary identity to the gateway in the IKE_AUTH request message and the gateway does acquire the real identity of the client after the EAP exchange, then the gateway can decide to redirect based on the true identity. The REDIRECT payload would then be sent in the IKE_AUTH response that carries the EAP success message. Vijay > > Thanks, > Yaron > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >> Sent: Tuesday, March 17, 2009 0:12 >> To: Yaron Sheffer; Tero Kivinen >> Cc: IPsecme WG >> Subject: RE: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft- >> ietf-ipsecme-ikev2-redirect-04) >> >> Hi Yaron, Tero, >> >> We don't really have a protocol extension (EAP, RADIUS or Diameter) for >> the AAA server to tell the IKEv2 gateway to redirect the client to >> another gateway. >> >> In addition, if there is an EAP exchange, the true identity of the >> client is not revealed to the gateway. >> >> So I am not sure on what basis the gateway would redirect the client in >> message #10 and #18 in Tero's email. >> http://www.ietf.org/mail-archive/web/ipsec/current/msg04025.html >> >> My proposal is to limit the REDIRECT payload to appear in message #4 (in >> the first IKE_AUTH response), based on the identity presented by the >> client. And leave EAP scenarios out of scope for this document. If >> someone wants the AAA server to redirect the client based on the EAP >> exchange, a separate document could be written. And this document can >> specify that the REDIRECT message can be sent in message 10. >> >> Does this sound good? >> >> Vijay >> >> On Thu, 2009-03-12 at 16:07 -0400, Yaron Sheffer wrote: >>> We should not do the redirect based on an asserted, unautheticated >> identity. >>> Going back to Tero's previous message on this thread, I think we should >>> allow redirect both in message 10 and 18 (i.e. following both EAP >> rounds, >>> and where the EAP state machine is "idle"). The gateway probably needs >> the >>> AAA server to tell it where to redirect to, anyway. >>> >>> In message 10 the gateway still doesn't know that the client wants to >>> perform secondary authentication, but I propose to ignore this issue for >>> simplicity. >>> >>> Thanks, >>> Yaron >>> >>>> -----Original Message----- >>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of >>>> Tero Kivinen >>>> Sent: Thursday, March 12, 2009 14:15 >>>> To: Vijay Devarapalli >>>> Cc: IPsecme WG; Yoav Nir; paul.hoffman@vpnc.org >>>> Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call: >>>> draft-ietf-ipsecme-ikev2-redirect-04) >>>> >>>> Vijay Devarapalli writes: >>>>> The one significant piece of information that the gateway has during >> the >>>>> IKE_AUTH exchange, that it didn't have during the IKE_SA_INIT >> exchange, >>>>> is the identity of the client. Some folks want to redirect the >> client >>>>> based on whatever identity it presents. So if thats they case, the >> first >>>>> IKE_AUTH response would be used for sending the REDIRECT payload. If >> the >>>>> gateway wanted to redirect the client because of load conditions, it >>>>> would have done it during the IKE_SA_INIT exchange itself. I don't >>>>> expect the EAP exchange or the multiple auth exchange to trigger a >>>>> redirect. We can make this explicit if needed. >>>> I tought someone wanted to do some kind of radius lookup to select >>>> where client is redirected to and in some cases client might not be >>>> sending the ID used for that in the ID payload but might use the EAP >>>> identity request/reply (even though RFC4306 3.16 says SHOULD NOT). >>>> >>>> If it will be enough to only see IDi to do redirect, meaning we can >>>> always restrict the REDIRECT to message 4, then it might be even >>>> acceptable to make that change. The main reason I was against having >>>> REDIRECTS in IKE_AUTHs is that there is so many locations where it can >>>> be and testing all possible combinations with all possible >>>> authentication methods and other extensions gets very complicated. >>>> -- >>>> kivinen@iki.fi >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>> >>>> Scanned by Check Point Total Security Gateway. >>>> >>>> Scanned by Check Point Total Security Gateway. >> Scanned by Check Point Total Security Gateway. From Pasi.Eronen@nokia.com Tue Mar 17 03:11:51 2009 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 B2B4C3A6B0B for ; Tue, 17 Mar 2009 03:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 wxrvKBlxzPND for ; Tue, 17 Mar 2009 03:11:50 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id B26303A68D1 for ; Tue, 17 Mar 2009 03:11:50 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2HACVOt016034 for ; Tue, 17 Mar 2009 05:12:33 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 12:12:14 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 12:12:14 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 17 Mar 2009 11:12:13 +0100 From: To: Date: Tue, 17 Mar 2009 11:12:12 +0100 Thread-Topic: Issue (resumption): Replays in 1-rtt protocol Thread-Index: Acmm6NbHIsNNHM9rSLC2xvyvdpa8XQ== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F1FB27FB@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Mar 2009 10:12:14.0050 (UTC) FILETIME=[D7D5B420:01C9A6E8] X-Nokia-AV: Clean Subject: [IPsec] Issue (resumption): Replays in 1-rtt protocol 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, 17 Mar 2009 10:11:51 -0000 Section 7.8 currently says that "In any case, a ticket replayed by an adversary only causes partial IKE state to be created on the gateway." Such partial IKE state is not really a big problem, since the only harm it causes is using a small amount of memory. The memory will be eventually freed, and as described in Section 4.3.2, if the gateway notices it's short on memory, it can do the COOKIE thing. What the draft does not yet describe is that IKE_SESSION_RESUME request replays can have other bad consequences in many circumstances. The VPN gateway often interacts with other components, and they cause problems that would not be solved by having infinite amount of RAM: - If the VPN gateway gets the IP addresses from a DHCP server, replays could consume addresses from the DHCP server pool, and use DHCP server processing resources (in addition to VPN gateway RAM). - If the VPN gateway acts as a Proxy MIP "Local Mobility Anchor", replay would cause a PBU message to be sent, which would consume resources at the MAG, and worse, break connectivity for the real client. - If a client can use the same IP address with different cluster members, replay would impact whatever mechanism the gateways use to keep track of which IP is where (e.g. injecting a host route via IGP, or claiming it via ARP/ND), causing load for the infrastructure and possibly breaking connectivity for the real client. - Many VPN gateways interact with AAA (RADIUS/Diameter) in some way. Replay could cause e.g. Accounting-Start message, authorization-only exchange, QoS related AAA stuff (e.g. draft-ietf-dime-diameter-qos), and so on. These would consume resources at the AAA infrastructure, and lead to incorrect data at AAA servers. - If the VPN gateway updates DNS records dynamically on behalf of the client, replay would consume DNS server resources, and possibly lead to incorrect data in the DNS. In some cases, like the DHCP server, it's relatively easy to "roll back" the incorrect state: when the VPN gateway deletes the partial IKE_SA state, it would also release DHCP lease. And in some cases, it might be possible to modify how the boxes interact so that attack becomes ineffective (e.g. don't send Accounting-Start immediately when the IKE_SA/IPsec SAs are created, but only when we've received some traffic proving that they're live). At any rate, the draft needs to describe this: it's not just a local optimization between the VPN client and gateway (saving network traffic and time), but can change how the VPN gateway fits in a larger architecture -- and the 2-roundtrip-version (Cookie exchange in Section 4.2.3) might be needed for many other reasons than VPN gateway having limited RAM. Best regards, Pasi= From Pasi.Eronen@nokia.com Tue Mar 17 03:15:43 2009 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 3608A28C0E0 for ; Tue, 17 Mar 2009 03:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.907 X-Spam-Level: X-Spam-Status: No, score=-5.907 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, 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 qgx6nVB4bFku for ; Tue, 17 Mar 2009 03:15:42 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 342353A697D for ; Tue, 17 Mar 2009 03:15:42 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2HAFaiM019040 for ; Tue, 17 Mar 2009 05:16:25 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 12:15:38 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 12:15:34 +0200 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 17 Mar 2009 11:15:33 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Tue, 17 Mar 2009 11:15:33 +0100 From: To: Date: Tue, 17 Mar 2009 11:15:26 +0100 Thread-Topic: Issue (resumption): SK_* not necessarily fresh? Thread-Index: Acmm6UqByMXcmB7fShmPeGL56s3AsQ== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F1FB2805@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Mar 2009 10:15:34.0247 (UTC) FILETIME=[4F295770:01C9A6E9] X-Nokia-AV: Clean Subject: [IPsec] Issue (resumption): SK_* not necessarily fresh? 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, 17 Mar 2009 10:15:43 -0000 If an attacker replays a valid IKE_SESSION_RESUME request (and the gateway/gateway cluster does not have state to detect this), then the SK_* keys used in the IKE_SESSION_RESUME response will not be fresh (since they depend only on the ticket and Ni). If the IKE_SA uses CBC mode encryption and HMAC for integrity, that's probably not a very big problem. But if the IKE_SA uses CTR, CCM or GCM mode, it probably is. I already pointed out this to the authors in December 2007, but the latest draft doesn't seem to say anything about it yet. Back then,=20 I argued that the simplest solution to this (and some other complexities) is a two-roundtrip-protocol, but if others think saving one RTT is worth the extra complexity, this is one part of that extra complexity that has to be addressed somehow... BTW, the COOKIE roundtrip in Section 4.3.2 does *not* solve this problem; a two-roundtrip version not having this problem would look something like this: HDR(A,0), Ni, N(TICKET_OPAQUE) -->=20 <-- HDR(A,B), Nr=20 [ calculate SKEYSEED =3D prf(old SK_d, Ni | Nr) ]=20 HDR(A,B), SK { AUTH, [CP], SAi2, TSi, TSr, } -->=20 [ AUTH =3D prf(SK_pi, ) ]=20 <-- HDR(A,B), SK { AUTH, [CP], SAr2, TSi, TSr }=20 [ AUTH =3D prf(SK_pr, ) ] Best regards, Pasi= From kivinen@iki.fi Tue Mar 17 03:17:25 2009 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 5FB9C3A684C for ; Tue, 17 Mar 2009 03:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 Gw-j9Z-Ys3k4 for ; Tue, 17 Mar 2009 03:17:24 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 306933A6B0C for ; Tue, 17 Mar 2009 03:17:19 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n2HAHtxD017529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Mar 2009 12:17:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n2HAHsjQ011168; Tue, 17 Mar 2009 12:17:54 +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: <18879.30930.703756.58201@fireball.kivinen.iki.fi> Date: Tue, 17 Mar 2009 12:17:54 +0200 From: Tero Kivinen To: Vijay Devarapalli In-Reply-To: <1237241498.5668.21.camel@vijay-ipv6-desktop> References: <18871.46432.577501.495334@fireball.kivinen.iki.fi> <49B829A9.6090300@wichorus.com> <18872.64682.15892.720908@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F616@il-ex01.ad.checkpoint.com> <1237241498.5668.21.camel@vijay-ipv6-desktop> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: IPsecme WG Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) 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, 17 Mar 2009 10:17:25 -0000 Vijay Devarapalli writes: > My proposal is to limit the REDIRECT payload to appear in message #4 (in > the first IKE_AUTH response), based on the identity presented by the > client. And leave EAP scenarios out of scope for this document. If others feel this is needed, I am willing to accept that solution, as it should still be fixed defined location, which means testing it will be simplier. > If someone wants the AAA server to redirect the client based on the > EAP exchange, a separate document could be written. And this > document can specify that the REDIRECT message can be sent in > message 10. In this case I would rather propose doing the IKE AUTH exchange completely and then using the INFORMATIONAL exchange to redirect the client, i.e. if REDIRECT is allowed in IKE_AUTH, only allow it in the first response IKE_AUTH packet of the exchage, and nowhere else. -- kivinen@iki.fi From Pasi.Eronen@nokia.com Tue Mar 17 03:19:11 2009 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 5D5163A697D for ; Tue, 17 Mar 2009 03:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 PEoCbuanU7oK for ; Tue, 17 Mar 2009 03:19:10 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 4C3323A68D1 for ; Tue, 17 Mar 2009 03:19:10 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2HAJSeL023416 for ; Tue, 17 Mar 2009 12:19:50 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 12:19:32 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 12:19:28 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 17 Mar 2009 11:19:27 +0100 From: To: Date: Tue, 17 Mar 2009 11:19:26 +0100 Thread-Topic: Issue (resumption): Resumptions vs. the old IKE_SA Thread-Index: Acmm6dm9SL1Nx4kzQ5i+c0VNw7YApA== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F1FB2816@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Mar 2009 10:19:28.0050 (UTC) FILETIME=[DA84D920:01C9A6E9] X-Nokia-AV: Clean Subject: [IPsec] Issue (resumption): Resumptions vs. the old IKE_SA 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, 17 Mar 2009 10:19:11 -0000 In TLS session resumption, resumption basically creates a new TLS "connection" (using information from local session cache, or ticket in case of RFC5077), and does *not* really resume the old connection. The old connection can still exist (and the session resumption handshake won't cause it to be closed), or it could have been interrupted earlier, or it could have been cleanly closed earlier. The current ikev2-resumption draft, on the other hand, seems to assume a quite different model, where resumption replaces the old connection, and can be done only if the old connection was interrupted. This would seem to preclude one case discussed earlier: I close my laptop (cleanly) at work, commute, and reconnect at home (without having to do EAP again; e.g. type in one-time password). Or "switch off my phone (cleanly), fly to IETF meeting, and switch it back on". In case of IKEv2, having multiple parallel IKE connections is probably less common than with TLS (where it's very common), but to me it seems using the IKE_SESSION_RESUME handshake when the old IKE_SA was cleanly closed would be quite useful, and should be supported. (And making the "new connection" completely independent of the old one might simplify the protocol anyway.) Best regards, Pasi= From Pasi.Eronen@nokia.com Tue Mar 17 04:26:55 2009 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 9AF1B3A6B14 for ; Tue, 17 Mar 2009 04:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 rAz+Ci9HkSJx for ; Tue, 17 Mar 2009 04:26:54 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 29A4C3A6B26 for ; Tue, 17 Mar 2009 04:26:53 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2HBRY9Z022269 for ; Tue, 17 Mar 2009 06:27:35 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 13:27:09 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 13:27:02 +0200 Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 17 Mar 2009 12:26:58 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Tue, 17 Mar 2009 12:26:58 +0100 From: To: Date: Tue, 17 Mar 2009 12:26:53 +0100 Thread-Topic: Issue (resumption): clarify what state comes from where Thread-Index: Acmm80YFSKCTa2ImRRiILxZdq+PKag== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F1FB2901@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Mar 2009 11:27:02.0014 (UTC) FILETIME=[4ADEA9E0:01C9A6F3] X-Nokia-AV: Clean Subject: [IPsec] Issue (resumption): clarify what state comes from where 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, 17 Mar 2009 11:26:55 -0000 When a session is resumed, both peers need to somehow get all the information they need for the new IKE_SA. Some of this comes from the ticket (on gateway side); some from local storage (on client side -- also gateway if using ticket-by reference); and some is fresh from the IKE exchanges. I think the draft needs some more clarification about where each piece comes from on each side. Much of this might actually be obvious to the authors, but e.g. as I noted in my 2008-11-18 email, the draft never actually says that in addition to storing the opaque ticket, the client also stores keys (and lot of other stuff) from its IKE_SA (and this was causing some confusion in IETF73)... and thus the text in Section 4.7 (saying that both peers take e.g. the SA value from the ticket) is not really correct (gateway does that, but not client, since the client can't parse the ticket). Also, when I started sketching a table summarizing this, I noticed that there are some pieces of information where the answer (where it comes from) is not totally clear. Here's my current sketch; parts that I found a bit unclear are marked with "???": +-----------------------------------------------------------------+ | Information | Client | Gateway | |------------------------+-----------------+----------------------| | IDi | local state | ticket/local state | |------------------------+-----------------+----------------------| | IDr | local state | ??? | |------------------------+-----------------+----------------------| | Certificates (note 1) | local state | ticket/local state | |------------------------+-----------------+----------------------| | local IP address/port | | from | | peer IP address/port | client selects | IKE_SESSION_RESUME | | (note 2) | | exchange | |------------------------+----------------------------------------| | NAT_DETECTION status | not resumed (NAT_DETECTION_* payloads | | | included in IKE_SESSION_RESUME) | |------------------------+----------------------------------------| | SPIs | fresh from IKE_SESSION_RESUME exchange | |------------------------+----------------------------------------| | Which peer is the | the one who initiates the | | "original initiator"? | IKE_SESSION_RESUME exchange | |------------------------+----------------------------------------| | IKE_SA sequence | start from 0 (for IKE_SESSION_RESUME | | numbers | request/response) | |------------------------+----------------------------------------| | IKE_SA algorithms | local state | ticket/local state | | (SAr) | | | |------------------------+----------------------------------------| | IKE_SA keys (SK_*) | See Section 4.7 | |------------------------+----------------------------------------| | IKE_SA window size | reset to 1 | |------------------------+----------------------------------------| | CHILD_SAs (ESP/AH) | not resumed (new CHILD_SAs created | | | from scratch) | |------------------------+----------------------------------------| | | not resumed (IKE_SESSION_RESUME | | Internal IP address | exchange can assign same or | | | different address) (note 3) | |------------------------+----------------------------------------| | Other CP information | not resumed | |------------------------+----------------------------------------| | Peer Vendor IDs | ??? | |------------------------+----------------------------------------| | Peer supports MOBIKE? | ??? | | [RFC4555] | | |------------------------+----------------------------------------| | MOBIKE additional | ??? | | addresses [RFC4555] | | |------------------------+----------------------------------------| | Time until | | | reauthentication | ??? | | [RFC4478] | | +-----------------------------------------------------------------+ | Peer supports | | | redirects? [draft-..] | ??? | +-----------------------------------------------------------------+ Note 1: Certificates don't need to be stored if the peer never uses them for anything after the IKE_SA is up (but would be needed if exposed to applications via IPsec APIs). Note 2: If the certificate has an iPAddress SubjectAltName, and the implementation requires it to match the peer source IP address, this check needs to be performed also on session resumption (and the required information saved locally or in the ticket). Note 3: The client can request the address it was using earlier, and if possible, the gateway should honor the request. Note 4: IKEv2 features that affect only the IKE_AUTH exchange (including HTTP_CERT_LOOKUP_SUPPORTED, multiple authentication exchanges [RFC4739], ECDSA authentication [RFC4754], and OCSP [RFC4806]) don't usually need any state in the IKE_SA (after the IKE_AUTH exchanges are done), so resumption doesn't affect them. Note 5: Since information about CHILD_SAs and configuration payloads is not resumed, IKEv2 features related to CHILD_SA negotiation (such as IPCOMP_SUPPORTED, ESP_TFC_PADDING_NOT_SUPPORTED, and ROHC-over-IPsec [draft-ietf-rohc-ikev2-extensions-hcoipsec-08]) and configuration aren't usually affected by session resumption. Note 6: New IKEv2 features that are not covered by notes 4 and 5 should specify how the interact with session resumption. Best regards, Pasi= From Pasi.Eronen@nokia.com Tue Mar 17 04:29:15 2009 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 BB1F53A6A13 for ; Tue, 17 Mar 2009 04:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 pfSjM5u7b8ZR for ; Tue, 17 Mar 2009 04:29:11 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 03F2B3A67D6 for ; Tue, 17 Mar 2009 04:29:10 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2HBThpd021335 for ; Tue, 17 Mar 2009 13:29:50 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 13:29:48 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 13:29:42 +0200 Received: from NOK-AM1MHUB-05.mgdnok.nokia.com (65.54.30.9) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 17 Mar 2009 12:29:42 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by NOK-AM1MHUB-05.mgdnok.nokia.com ([65.54.30.9]) with mapi; Tue, 17 Mar 2009 12:29:42 +0100 From: To: Date: Tue, 17 Mar 2009 12:29:41 +0100 Thread-Topic: Issue: Minor nits for ikev2-resumption-02 Thread-Index: Acmm86nCu0TttYU+QR+vQmlUBsGcaA== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F1FB290D@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Mar 2009 11:29:42.0965 (UTC) FILETIME=[AACDD650:01C9A6F3] X-Nokia-AV: Clean Subject: [IPsec] Issue: Minor nits for ikev2-resumption-02 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, 17 Mar 2009 11:29:15 -0000 Couple of trivial things noted when reading the latest draft: - Section 4.1/4.2 should probably clarify that when multi-round-trip IKE_AUTH exchange is used, N(TICKET_REQUEST) is included in the first IKE_AUTH request, and N(TICKET_OPAQUE) (or TICKET_NACK/TICKET_ACK) is in the final IKE_AUTH response. - Section 4.4 should say that the Protocol ID and SPI Size fields for all these notifications are set to zero. - Section 4.5 should say that lifetime is relative to the current time (and not e.g. POSIX-style timestamp() - IANA considerations: should say that TBA1...TBA5 numbers come from the "Status Types" part of the notification registry=20 Best regards, Pasi= From yaronf@checkpoint.com Tue Mar 17 04:33:06 2009 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 58E9828C131 for ; Tue, 17 Mar 2009 04:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.783 X-Spam-Level: X-Spam-Status: No, score=-2.783 tagged_above=-999 required=5 tests=[AWL=-0.184, 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 1zSKK8ssGDl3 for ; Tue, 17 Mar 2009 04:33:05 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id EA8C828C0DB for ; Tue, 17 Mar 2009 04:33:04 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 0ECB92CC002; Tue, 17 Mar 2009 13:33:47 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 9F3392CC003; Tue, 17 Mar 2009 13:33:44 +0200 (IST) X-CheckPoint: {49BF895A-0-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n2HBXh17025614; Tue, 17 Mar 2009 13:33:44 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 17 Mar 2009 13:33:43 +0200 From: Yaron Sheffer To: Tero Kivinen , Vijay Devarapalli Date: Tue, 17 Mar 2009 13:33:41 +0200 Thread-Topic: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) Thread-Index: Acmm6aajGjdy1BCPQm+n7Pkwxb4YwgACdNHg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F9F4@il-ex01.ad.checkpoint.com> References: <18871.46432.577501.495334@fireball.kivinen.iki.fi> <49B829A9.6090300@wichorus.com> <18872.64682.15892.720908@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F616@il-ex01.ad.checkpoint.com> <1237241498.5668.21.camel@vijay-ipv6-desktop> <18879.30930.703756.58201@fireball.kivinen.iki.fi> In-Reply-To: <18879.30930.703756.58201@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0103_01C9A704.FC747C50" MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) 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, 17 Mar 2009 11:33:06 -0000 ------=_NextPart_000_0103_01C9A704.FC747C50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tero, Vijay, I'm all for restricting Redirect to only one fixed defined location. But I suggest that this location should be the *last* message of IKE_AUTH, whether you're using EAP or not. This would be message #4 in barebones IKE, message #18 in Tero's long example. I don't think a security protocol should perform operations based on asserted, unauthenticated identity. Thanks, Yaron > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Tuesday, March 17, 2009 12:18 > To: Vijay Devarapalli > Cc: Yaron Sheffer; IPsecme WG > Subject: RE: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft- > ietf-ipsecme-ikev2-redirect-04) > > Vijay Devarapalli writes: > > My proposal is to limit the REDIRECT payload to appear in message #4 (in > > the first IKE_AUTH response), based on the identity presented by the > > client. And leave EAP scenarios out of scope for this document. > > If others feel this is needed, I am willing to accept that solution, > as it should still be fixed defined location, which means testing it > will be simplier. > > > If someone wants the AAA server to redirect the client based on the > > EAP exchange, a separate document could be written. And this > > document can specify that the REDIRECT message can be sent in > > message 10. > > In this case I would rather propose doing the IKE AUTH exchange > completely and then using the INFORMATIONAL exchange to redirect the > client, i.e. if REDIRECT is allowed in IKE_AUTH, only allow it in the > first response IKE_AUTH packet of the exchage, and nowhere else. > -- > kivinen@iki.fi > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0103_01C9A704.FC747C50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDMxNzExMzM0MVowIwYJKoZIhvcNAQkEMRYEFOB3ZhjYNbMF lFX9kI589IH/nkAOMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA HCGodawky21HyJlk12DEqJG7TMGNaoCRNDyDL4EfXAntVXSyAgkJl6GL/+mS8mjku8XA7APssjzt R0EfpxYed4TyFVRM5/pkpbDRgMsNT/+IaaD3UoEuV/0VP7Ko4ks/9XFk8D6GjAHyPQFIu4bFjWOj KFsTzpqdT0d8FeeojdmkUCOKZBI7Dv/M8PSQ50YVjZ8Gii04K/5sln/TCSqtXoFOtpJGa7RX/of2 gusrrG4yQPE+aZMo/clvSYfTC7JTRDNGHYRQ0sjmOYUN6Jo2x4PWwe+4JGJ+MQUc/xTZhmNaq0qN Q02Mai9homDK1BqV7hP1RiqfdSkTPr/NvkneMAAAAAAAAA== ------=_NextPart_000_0103_01C9A704.FC747C50-- From yaronf@checkpoint.com Tue Mar 17 09:02:31 2009 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 C7D243A6A25 for ; Tue, 17 Mar 2009 09:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=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 kxiugvWJ8s+W for ; Tue, 17 Mar 2009 09:02:31 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id D78D33A68D5 for ; Tue, 17 Mar 2009 09:02:29 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D18152CC002; Tue, 17 Mar 2009 18:03:11 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6E68B2CC001; Tue, 17 Mar 2009 18:03:10 +0200 (IST) X-CheckPoint: {49BFC87C-0-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n2HG3916008073; Tue, 17 Mar 2009 18:03:09 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 17 Mar 2009 18:03:09 +0200 From: Yaron Sheffer To: "Pasi.Eronen@nokia.com" , "ipsec@ietf.org" Date: Tue, 17 Mar 2009 18:03:07 +0200 Thread-Topic: Issue (resumption): SK_* not necessarily fresh? Thread-Index: Acmm6UqByMXcmB7fShmPeGL56s3AsQAJt2ow Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D7C3CD@il-ex01.ad.checkpoint.com> References: <808FD6E27AD4884E94820BC333B2DB7727F1FB2805@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F1FB2805@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_011E_01C9A72A.A01D0050" MIME-Version: 1.0 Subject: Re: [IPsec] Issue (resumption): SK_* not necessarily fresh? 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, 17 Mar 2009 16:02:31 -0000 ------=_NextPart_000_011E_01C9A72A.A01D0050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Pasi, Thanks for your extensive comments. One way to deal with the attack you present here is by adding a nonce to the responder's side: HDR, Ni, N(TICKET_OPAQUE'), [N+,] SK{...} --> <-- HDR, Nr', SK'{Nr, SAr2, [TSi, TSr], ...} Where Nr' is the new nonce, SK' depends on the ticket, Ni and Nr'. Would that resolve the freshness issue? Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Pasi.Eronen@nokia.com > Sent: Tuesday, March 17, 2009 12:15 > To: ipsec@ietf.org > Subject: [IPsec] Issue (resumption): SK_* not necessarily fresh? > > > > If an attacker replays a valid IKE_SESSION_RESUME request (and the > gateway/gateway cluster does not have state to detect this), then the > SK_* keys used in the IKE_SESSION_RESUME response will not be fresh > (since they depend only on the ticket and Ni). > > If the IKE_SA uses CBC mode encryption and HMAC for integrity, that's > probably not a very big problem. But if the IKE_SA uses CTR, CCM or > GCM mode, it probably is. > > I already pointed out this to the authors in December 2007, but the > latest draft doesn't seem to say anything about it yet. Back then, > I argued that the simplest solution to this (and some other > complexities) is a two-roundtrip-protocol, but if others think saving > one RTT is worth the extra complexity, this is one part of that extra > complexity that has to be addressed somehow... > > BTW, the COOKIE roundtrip in Section 4.3.2 does *not* solve this > problem; a two-roundtrip version not having this problem would look > something like this: > > HDR(A,0), Ni, N(TICKET_OPAQUE) --> > <-- HDR(A,B), Nr > [ calculate SKEYSEED = prf(old SK_d, Ni | Nr) ] > HDR(A,B), SK { AUTH, [CP], SAi2, TSi, TSr, } --> > [ AUTH = prf(SK_pi, ) ] > <-- HDR(A,B), SK { AUTH, [CP], SAr2, TSi, TSr } > [ AUTH = prf(SK_pr, ) ] > > Best regards, > Pasi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_011E_01C9A72A.A01D0050 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDMxNzE2MDMwN1owIwYJKoZIhvcNAQkEMRYEFN5A+uD9RHHT 8Tyz8PU1bTz77rdtMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA rS7D1OpCw9pi551Ktcqxvoh5hWHELkG6uGIm5UVwpSakypdLWE2gzqal0OjJKt0BGNrXPyxLHEd6 6Z7UUYyw5rTaI0v0YYbf6HlUfVuKhcPNHt97m4FPfRC1TZq4dVkXcIo65hRq3Rcqk+KFfP8HfVOW 3gnalbkSCOf0oqZb3Iuv9XFJuJHEMhfCGCvWRqK8RnWC37Fyt8eC6v2PkKh0Cac3wL2tm22d+tpr KcZKHWwEO6Es5OQFduogJQkugTGTikVT20TRe/TdOaRIUCQDT7hVnyaaaxEpdXIBizl63z6xUQVv mXCaql8bkmR0ieQ7SxYLfSWZ914WkoBPouYtKQAAAAAAAA== ------=_NextPart_000_011E_01C9A72A.A01D0050-- From saddepalli@freescale.com Tue Mar 17 09:39:56 2009 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 BD6A13A6818 for ; Tue, 17 Mar 2009 09:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prz9BWbIjsUP for ; Tue, 17 Mar 2009 09:39:55 -0700 (PDT) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id A019D3A6ADF for ; Tue, 17 Mar 2009 09:39:52 -0700 (PDT) Received: from az33smr01.freescale.net (az33smr01.freescale.net [10.64.34.199]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id n2HGeWu4013382 for ; Tue, 17 Mar 2009 09:40:34 -0700 (MST) Received: from az33exm23.fsl.freescale.net (az33exm23.am.freescale.net [10.64.32.8]) by az33smr01.freescale.net (8.13.1/8.13.0) with ESMTP id n2HGeVTC013084 for ; Tue, 17 Mar 2009 11:40:31 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Mar 2009 09:40:31 -0700 Message-ID: <28BD9D0449D7604C86B766235FA9A8C906B6F9C5@az33exm23.fsl.freescale.net> In-Reply-To: <49BED8F9.5000403@wichorus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Redirect during IKE_AUTH (was Re: WG LastCall:draft-ietf-ipsecme-ikev2-redirect-04) Thread-Index: AcmminRoVQb7kDD8SLS5Eq+oP4RqWAADqAZQ References: <18871.46432.577501.495334@fireball.kivinen.iki.fi> <49B829A9.6090300@wichorus.com> <18872.64682.15892.720908@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F616@il-ex01.ad.checkpoint.com><1237241498.5668.21.camel@vijay-ipv6-desktop><7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F932@il-ex01.ad.checkpoint.com> <49BED8F9.5000403@wichorus.com> From: "Addepalli Srini-B22160" To: "Vijay Devarapalli" , "Yaron Sheffer" Cc: IPsecme WG , Tero Kivinen Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG LastCall:draft-ietf-ipsecme-ikev2-redirect-04) 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, 17 Mar 2009 16:39:56 -0000 Hi Vijay, Sending "REDIRECT" notification upon receiving IKE_SA_INIT request solves the load issue.=20 Sending "REDIRECT" notification as part of first IKE_AUTH response satisfies selection of VPN responder based on IDi. Based on my understanding, even 3GPP IMSI is sent along with IDi. This information (typically some portion of it) can be used to figure out the right VPN Server to redirect.=20 Yet times, based on the type of internal network the user is accessing, VPN server might decide to redirect the user to some other VPN Server to improve user experience. I guess this case is handled in the draft under section 'Gateway Initiated Redirect". Though it seems fine sending "Redirect" notification along with "EAP SUCCESS" as part of AUTH response, I am wondering the deployment use cases for this. If Authentication is successful, then I guess majority of heavy work is already done by VPN gateway and it is better if it continues to serve the user.=20 Regards Srini -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Vijay Devarapalli Sent: Monday, March 16, 2009 3:56 PM To: Yaron Sheffer Cc: IPsecme WG; Tero Kivinen Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG LastCall:draft-ietf-ipsecme-ikev2-redirect-04) Yaron Sheffer wrote: > Hi Vijay, >=20 > I don't have the details at hand, but in 3GPP land it is common for the > client to send all sorts of temporary identities, and for the AAA server to > respond to the Packet Data Gateway (that's our gateway) with the client's > "true" identity (IMSI, MSISDN, whatever). Such permanent identity could > serve as the basis for a redirect decision. Do we have people on the list > familiar with these specs? I am aware of these specs. The last EAP message with "Success" from the=20 AAA server to the gateway, has the real identity of the client as a=20 RADIUS attribute (for example). But we don't have a reference for this=20 in the IETF, since RFC 4306 says that there shouldn't be an EAP Identity Request/Response exchange. In RFC 4877, we did mention that the Mobile IPv6 home agent MUST acquire the true identity of the mobile node when EAP is used, but left the=20 actual mechanism out of scope. Section 8 of RFC 4877 says When EAP is used, the identity presented by the mobile node in the IDi field may not be the actual identity of the mobile node. It could be set to an identity that is used only for Authentication, Authorization, and Accounting (AAA) routing purposes and selecting the right EAP method. It is possible that the actual identity is carried inside EAP, invisible to the home agent. While IKEv2 does not allow an EAP Identity Request/Response message exchange, EAP methods may exchange identities within themselves. In this case, the home agent MUST acquire the mobile node's identity from the corresponding AAA server. How the home agent acquires the mobile node's identity is out of scope for this document. One option would to be adapt the above text to say that if the client=20 had presented a temporary identity to the gateway in the IKE_AUTH=20 request message and the gateway does acquire the real identity of the=20 client after the EAP exchange, then the gateway can decide to redirect=20 based on the true identity. The REDIRECT payload would then be sent in=20 the IKE_AUTH response that carries the EAP success message. Vijay >=20 > Thanks, > Yaron >=20 >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >> Sent: Tuesday, March 17, 2009 0:12 >> To: Yaron Sheffer; Tero Kivinen >> Cc: IPsecme WG >> Subject: RE: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft- >> ietf-ipsecme-ikev2-redirect-04) >> >> Hi Yaron, Tero, >> >> We don't really have a protocol extension (EAP, RADIUS or Diameter) for >> the AAA server to tell the IKEv2 gateway to redirect the client to >> another gateway. >> >> In addition, if there is an EAP exchange, the true identity of the >> client is not revealed to the gateway. >> >> So I am not sure on what basis the gateway would redirect the client in >> message #10 and #18 in Tero's email. >> http://www.ietf.org/mail-archive/web/ipsec/current/msg04025.html >> >> My proposal is to limit the REDIRECT payload to appear in message #4 (in >> the first IKE_AUTH response), based on the identity presented by the >> client. And leave EAP scenarios out of scope for this document. If >> someone wants the AAA server to redirect the client based on the EAP >> exchange, a separate document could be written. And this document can >> specify that the REDIRECT message can be sent in message 10. >> >> Does this sound good? >> >> Vijay >> >> On Thu, 2009-03-12 at 16:07 -0400, Yaron Sheffer wrote: >>> We should not do the redirect based on an asserted, unautheticated >> identity. >>> Going back to Tero's previous message on this thread, I think we should >>> allow redirect both in message 10 and 18 (i.e. following both EAP >> rounds, >>> and where the EAP state machine is "idle"). The gateway probably needs >> the >>> AAA server to tell it where to redirect to, anyway. >>> >>> In message 10 the gateway still doesn't know that the client wants to >>> perform secondary authentication, but I propose to ignore this issue for >>> simplicity. >>> >>> Thanks, >>> Yaron >>> >>>> -----Original Message----- >>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of >>>> Tero Kivinen >>>> Sent: Thursday, March 12, 2009 14:15 >>>> To: Vijay Devarapalli >>>> Cc: IPsecme WG; Yoav Nir; paul.hoffman@vpnc.org >>>> Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call: >>>> draft-ietf-ipsecme-ikev2-redirect-04) >>>> >>>> Vijay Devarapalli writes: >>>>> The one significant piece of information that the gateway has during >> the >>>>> IKE_AUTH exchange, that it didn't have during the IKE_SA_INIT >> exchange, >>>>> is the identity of the client. Some folks want to redirect the >> client >>>>> based on whatever identity it presents. So if thats they case, the >> first >>>>> IKE_AUTH response would be used for sending the REDIRECT payload. If >> the >>>>> gateway wanted to redirect the client because of load conditions, it >>>>> would have done it during the IKE_SA_INIT exchange itself. I don't >>>>> expect the EAP exchange or the multiple auth exchange to trigger a >>>>> redirect. We can make this explicit if needed. >>>> I tought someone wanted to do some kind of radius lookup to select >>>> where client is redirected to and in some cases client might not be >>>> sending the ID used for that in the ID payload but might use the EAP >>>> identity request/reply (even though RFC4306 3.16 says SHOULD NOT). >>>> >>>> If it will be enough to only see IDi to do redirect, meaning we can >>>> always restrict the REDIRECT to message 4, then it might be even >>>> acceptable to make that change. The main reason I was against having >>>> REDIRECTS in IKE_AUTHs is that there is so many locations where it can >>>> be and testing all possible combinations with all possible >>>> authentication methods and other extensions gets very complicated. >>>> -- >>>> kivinen@iki.fi >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>> >>>> Scanned by Check Point Total Security Gateway. >>>> >>>> Scanned by Check Point Total Security Gateway. >> Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From saddepalli@freescale.com Tue Mar 17 10:59:54 2009 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 B0AB43A6968 for ; Tue, 17 Mar 2009 10:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41JLKN1aHION for ; Tue, 17 Mar 2009 10:59:53 -0700 (PDT) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id DC3043A6955 for ; Tue, 17 Mar 2009 10:59:53 -0700 (PDT) Received: from de01smr02.am.mot.com (de01smr02.freescale.net [10.208.0.151]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id n2HI0MJD010427 for ; Tue, 17 Mar 2009 11:00:24 -0700 (MST) Received: from az33exm23.fsl.freescale.net (az33exm23.am.freescale.net [10.64.32.8]) by de01smr02.am.mot.com (8.13.1/8.13.0) with ESMTP id n2HI0Ll3009350 for ; Tue, 17 Mar 2009 13:00:21 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Mar 2009 11:00:21 -0700 Message-ID: <28BD9D0449D7604C86B766235FA9A8C906B6F9FD@az33exm23.fsl.freescale.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavior of VPN Gateway when Client does not accept/ignores REDIRECT notification Thread-Index: AcmnKj0HzhRcHcimRtCbgqdWbAZyYA== From: "Addepalli Srini-B22160" To: Cc: IPsecme WG Subject: [IPsec] Behavior of VPN Gateway when Client does not accept/ignores REDIRECT notification 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, 17 Mar 2009 17:59:54 -0000 >From the draft, it is not clear on the VPN Responder behavior if Initiator proceeds with SA establishment even after receiving "REDIRECT" notification from the VPN Gateway. Draft indicates following: When the VPN client receives the IKE_SA_INIT response with the REDIRECT payload, it initiates a new IKE_SA_INIT exchange with the VPN gateway listed in the REDIRECT payload. The VPN client includes the IP address of the original VPN gateway that redirected the client. The IKEv2 exchange then proceeds as normal with the selected VPN gateway. =09 I believe that VPN gateway should not stop Client proceeding further with IKE negotiation even after it sends the REDIRECT notification in response to IKE_SA_INIT message. If that is what is intended, it is good if above text clarifies that further. Thanks Srini From saddepalli@freescale.com Tue Mar 17 12:35:07 2009 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 4BFCF3A6B2B for ; Tue, 17 Mar 2009 12:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7sIAl0Svzxc for ; Tue, 17 Mar 2009 12:35:06 -0700 (PDT) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id 8A1D03A6AB9 for ; Tue, 17 Mar 2009 12:35:06 -0700 (PDT) Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id n2HJZkBH010004 for ; Tue, 17 Mar 2009 12:35:47 -0700 (MST) Received: from az33exm23.fsl.freescale.net (az33exm23.am.freescale.net [10.64.32.8]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id n2HJZkxt022248 for ; Tue, 17 Mar 2009 14:35:46 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Mar 2009 12:35:34 -0700 Message-ID: <28BD9D0449D7604C86B766235FA9A8C906B6FA3B@az33exm23.fsl.freescale.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DoS Attack Possibility? Thread-Index: AcmnN4rEbuUb62ZGT+6AQyBBt9xWOw== From: "Addepalli Srini-B22160" To: Cc: IPsecme WG Subject: [IPsec] DoS Attack Possibility? 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, 17 Mar 2009 19:35:07 -0000 REDIRECT notification by the responder upon receiving IKE_SA_INIT might be exploited by intelligent injection of REDIRECT notifications. In site-to-site VPN case, it is not difficult for attackers to know IP addresses of gateways. UDP source port and destination ports are known. If attacker guesses the Initiator SPI, it is possible to DoS the VPN Initiator. This problem compounds if Initiator caches the information from REDIRECT notification. This attack is similar to DNS Poisoning attack which became famous in 2008. =20 If the initiator SPI is random data, then guessing would be nearly impossible and we don't need to worry about it. I was told that Initiator SPI was not mandated to be random in IKEv2 specifications (Though this problem may not be there in IKEv1 as Cookies are expected to be random - but we are not discussing IKEv1 here in this context). If that was the case indeed, then I think that we need to have some mechanism to thwart these kinds of attacks. One possible solution would be to send RANDOM data as part of "REDIRECTION_SUPPORTED" and expect this RANDOM to be seen in "REDIRECT" notification. Regards Srini =20 From kanno-s@po.ntts.co.jp Tue Mar 17 19:39:19 2009 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 D02093A6822 for ; Tue, 17 Mar 2009 19:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.217 X-Spam-Level: X-Spam-Status: No, score=0.217 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 zeS25DL95fbI for ; Tue, 17 Mar 2009 19:39:19 -0700 (PDT) Received: from mail2.ics.ntts.co.jp (mail2.ics.ntts.co.jp [202.32.24.42]) by core3.amsl.com (Postfix) with ESMTP id DDC613A6860 for ; Tue, 17 Mar 2009 19:39:18 -0700 (PDT) Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail2.ics.ntts.co.jp (8.13.8/NTTSOFT) with ESMTP id n2I2e2G8004708 for ; Wed, 18 Mar 2009 11:40:02 +0900 (JST) Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.8/NTTSOFT) id n2I2e2eL012228 for ipsec@ietf.org; Wed, 18 Mar 2009 11:40:02 +0900 (JST) Received: from ccm19.silk.ntts.co.jp [10.7.18.19] by sadoku34.silk.ntts.co.jp with SMTP id MAA12147; Wed, 18 Mar 2009 11:39:46 +0900 Received: from mail16.silk.ntts.co.jp (localhost [127.0.0.1]) by ccm19.silk.ntts.co.jp (8.14.3/NTTSOFT) with ESMTP id n2I2dkUM004494; Wed, 18 Mar 2009 11:39:46 +0900 (JST) Received: from mail16.silk.ntts.co.jp (localhost [127.0.0.1]) by mail16.silk.ntts.co.jp (8.14.3/NTTSOFT) with ESMTP id n2I2dkRa022795; Wed, 18 Mar 2009 11:39:46 +0900 (JST) Received: from [127.0.0.1] ([10.7.206.148]) by mail16.silk.ntts.co.jp (8.14.3/NTTSOFT) with ESMTP id n2I2dblr022735; Wed, 18 Mar 2009 11:39:46 +0900 (JST) Date: Wed, 18 Mar 2009 11:39:38 +0900 From: Satoru Kanno To: IPsecme WG X-Face: ,\m{?h\)X Message-Id: <20090318113747.A0A2.KANNO-S@po.ntts.co.jp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------_49C05E7AA0C906DF68E8_MULTIPART_MIXED_" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.02 [ja] X-CC-Mail-RelayStamp: CC-Mail-V4-Client X-CC-Mail-RelayStamp: CC-Mail-V4-Server Subject: [IPsec] New draft 'The Camellia XCBC-96 and XCBC-PRF-128' 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, 18 Mar 2009 02:39:19 -0000 --------_49C05E7AA0C906DF68E8_MULTIPART_MIXED_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, Lists, We wrote up new draft 'The Camellia XCBC-96 and XCBC-PRF-128'. This draft is also to adopt addition of Camellia algorithm for IPsec. We think that it is proper to deal with as an individual submission. This draft is not in I-D repository, but will appear A.S.A.P after 23 March 2009 at midnight(PT). Comments and questions about our document would be welcome. Best regards, -- Satoru Kanno Security Business Unit Mobile and Security Solution Business Group NTT Software Corporation e-mail: kanno-s@po.ntts.co.jp --------_49C05E7AA0C906DF68E8_MULTIPART_MIXED_ Content-Type: application/octet-stream; name="draft-kanno-ipsecme-camellia-xcbc-00.txt" Content-Disposition: attachment; filename="draft-kanno-ipsecme-camellia-xcbc-00.txt" Content-Transfer-Encoding: base64 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFMuIEthbm5vCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIE5UVCBTb2Z0d2FyZSBDb3Jwb3JhdGlvbgpJbnRlbmRlZCBzdGF0dXM6IFN0YW5k YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gS2FuZGEKRXhwaXJl czogU2VwdGVtYmVyIDE5LCAyMDA5ICAgICAgICAgICAgICAgTmlwcG9uIFRlbGVncmFwaCBhbmQg VGVsZXBob25lCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBDb3Jwb3JhdGlvbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMTgsIDIwMDkKCgogVGhlIENhbWVsbGlh LVhDQkMtOTYgYW5kIENhbWVsbGlhLVhDQkMtUFJGLTEyOCBBbGdvcml0aG1zIGFuZCBJdHMgVXNl CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3aXRoIElQc2VjCiAgICAgICAgICAgICAg ICAgIGRyYWZ0LWthbm5vLWlwc2VjbWUtY2FtZWxsaWEteGNiYy0wMAoKU3RhdHVzIG9mIHRoaXMg TWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgdG8gSUVURiBpbiBmdWxs IGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzku CgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5l dCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdv cmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0CiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmli dXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQogICBEcmFmdHMuCgogICBJbnRlcm5l dC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBt b250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90 aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNl IEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhlIGxpc3Qgb2YgY3VycmVu dCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4KCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0 IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9zaGFkb3cuaHRtbC4KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24g U2VwdGVtYmVyIDE5LCAyMDA5LgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJpZ2h0IChjKSAy MDA5IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlCiAgIGRvY3Vt ZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKICAgVGhpcyBkb2N1bWVudCBpcyBz dWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbAogICBQcm92aXNpb25z IFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBw dWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50IChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNl bnNlLWluZm8pLgogICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cyBjYXJlZnVsbHksIGFz IHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMKICAgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3Bl Y3QgdG8gdGhpcyBkb2N1bWVudC4KCgoKCgoKS2Fubm8gJiBLYW5kYSAgICAgICAgICBFeHBpcmVz IFNlcHRlbWJlciAxOSwgMjAwOSAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJh ZnQgICAgVGhlIENhbWVsbGlhIFhDQkMtOTYgYW5kIFhDQkMtUFJGLTEyOCAgICAgICBNYXJjaCAy MDA5CgoKQWJzdHJhY3QKCiAgIFRoaXMgbWVtbyBzcGVjaWZpZXMgdHdvIG5ldyBhbGdvcml0aG1z LiAgT25lIGlzIHRoZSB1c2FnZSBvZiBYQ0JDCiAgIG1vZGUgd2l0aCBDYW1lbGxpYSBibG9jayBj aXBoZXIgb24gdGhlIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBvZgogICB0aGUgSVBzZWMgRW5j YXBzdWxhdGluZyBTZWN1cml0eSBQYXlsb2FkIGFuZCBBdXRoZW50aWNhdGlvbiBIZWFkZXIKICAg cHJvdG9jb2xzLiAgVGhpcyBhbGdvcml0aG0gaXMgY2FsbGVkIENhbWVsbGlhLVhDQkMtOTYuICBM YXR0ZXIgaXMKICAgcHNldWRvLXJhbmRvbSBmdW5jdGlvbiBiYXNlZCBvbiBYQ0JDIHdpdGggQ2Ft ZWxsaWEgYmxvY2sgY2lwaGVyIGZvcgogICBJbnRlcm5ldCBLZXkgRXhjaGFuZ2UuICBUaGlzIGFs Z29yaXRobSBpcyBjYWxsZWQgQ2FtZWxsaWEtWENCQy1QUkYtCiAgIDEyOC4KCgpUYWJsZSBvZiBD b250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzCiAgICAgMS4xLiAgVGVybWlub2xvZ3kgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMwogICAyLiAgQ2FtZWxsaWEt WENCQy05NiBhbmQgQ2FtZWxsaWEtWENCQy1QUkYtMTI4IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQK ICAgMy4gIFRlc3QgVmVjdG9ycyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA1CiAgICAgMy4xLiAgQ2FtZWxsaWEtWENCQy05NiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICAgIDMuMi4gIENhbWVsbGlhLVhDQkMt UFJGLTEyOCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcKICAgNC4gIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA4CiAgIDUuICBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgOQogICA2LiAgQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTAKICAgNy4gIFJlZmVyZW5jZXMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAg ICAgNy4xLiAgTm9ybWF0aXZlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAxMQogICAgIDcuMi4gIEluZm9ybWF0aXZlICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEKICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgpLYW5ubyAmIEthbmRhICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDE5 LCAyMDA5ICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICBUaGUgQ2Ft ZWxsaWEgWENCQy05NiBhbmQgWENCQy1QUkYtMTI4ICAgICAgIE1hcmNoIDIwMDkKCgoxLiAgSW50 cm9kdWN0aW9uCgogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0d28gbmV3IGFsZ29yaXRobXMu ICBPbmUgaXMgdGhlIHVzYWdlIG9mIFhDQkMKICAgYmFzZWQgb24gQ2FtZWxsaWEgYmxvY2sgY2lw aGVyIG9uIHRoZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gb2YgdGhlCiAgIElQc2VjIEVuY2Fw c3VsYXRpbmcgU2VjdXJpdHkgUGF5bG9hZCAoRVNQKSBbN10gYW5kIEF1dGhlbnRpY2F0aW9uCiAg IEhlYWRlciBwcm90b2NvbHMgKEFIKSBbNl0uICBUaGlzIGFsZ29yaXRobSBpcyBjYWxsZWQKICAg Q2FtZWxsaWEtWENCQy05Ni4gIExhdHRlciBpcyBQc2V1ZG8tUmFuZG9tIEZ1bmN0aW9uIChQUkYp IGJhc2VkIG9uCiAgIFhDQkMgd2l0aCBDYW1lbGxpYSBibG9jayBjaXBoZXIgZm9yIEludGVybmV0 IEtleSBFeGNoYW5nZSAoSUtFdjIpCiAgIFs4XS4gIFRoaXMgYWxnb3JpdGhtIGlzIGNhbGxlZCBD YW1lbGxpYS1YQ0JDLVBSRi0xMjguCgogICBUaGUgQ2FtZWxsaWEgYWxnb3JpdGhtIHNwZWNpZmlj YXRpb24gYW5kIG9iamVjdCBpZGVudGlmaWVycyBhcmUKICAgZGVzY3JpYmVkIGluIFsyXS4KCjEu MS4gIFRlcm1pbm9sb2d5CgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJF UVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIs ICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50 IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gWzFdLgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgpLYW5ubyAmIEthbmRhICAgICAgICAgIEV4cGlyZXMgU2VwdGVt YmVyIDE5LCAyMDA5ICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICBU aGUgQ2FtZWxsaWEgWENCQy05NiBhbmQgWENCQy1QUkYtMTI4ICAgICAgIE1hcmNoIDIwMDkKCgoy LiAgQ2FtZWxsaWEtWENCQy05NiBhbmQgQ2FtZWxsaWEtWENCQy1QUkYtMTI4CgogICBUaGUgQ2Ft ZWxsaWEtWENCQy05NiBjb21wbHkgd2l0aCBbM10uICBBbHNvLCBUaGUgQ2FtZWxsaWEtWENCQy1Q UkYtCiAgIDEyOCBjb21wbHkgd2l0aCBbNF0uCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKS2Fubm8gJiBLYW5kYSAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJl ciAxOSwgMjAwOSAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgVGhl IENhbWVsbGlhIFhDQkMtOTYgYW5kIFhDQkMtUFJGLTEyOCAgICAgICBNYXJjaCAyMDA5CgoKMy4g IFRlc3QgVmVjdG9ycwoKMy4xLiAgQ2FtZWxsaWEtWENCQy05NgoKICAgVGhpcyBzZWN0aW9uIGNv bnRhaW5zIHNldmVuIHRlc3QgdmVjdG9ycyhUViksIHdoaWNoIGNhbiBiZSB1c2VkIHRvCiAgIGNv bmZpcm0gdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBoYXMgY29ycmVjdGx5IGltcGxlbWVudGVkIENh bWVsbGlhLQogICBYQ0JDLTk2LgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCkthbm5vICYgS2FuZGEgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTksIDIwMDkg ICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAgIFRoZSBDYW1lbGxpYSBY Q0JDLTk2IGFuZCBYQ0JDLVBSRi0xMjggICAgICAgTWFyY2ggMjAwOQoKCiAgICAgVGVzdCBDYXNl ICMxICAgICAgICA6IENhbWVsbGlhLVhDQkMtTUFDLTk2IHdpdGggMC1ieXRlIGlucHV0CiAgICAg S2V5IChLKSAgICAgICAgICAgICA6IDAwMDEwMjAzMDQwNTA2MDcwODA5MGEwYjBjMGQwZTBmCiAg ICAgTWVzc2FnZSAoTSkgICAgICAgICA6IDxlbXB0eSBzdHJpbmc8CiAgICAgQ2FtZWxsaWEtWENC Qy1NQUMgICA6IDxUQkQ+CiAgICAgQ2FtZWxsaWEtWENCQy1NQUMtOTY6IDxUQkQ+CgogICAgIFRl c3QgQ2FzZSAjMiAgICAgICAgOiBDYW1lbGxpYS1YQ0JDLU1BQy05NiB3aXRoIDMtYnl0ZSBpbnB1 dAogICAgIEtleSAoSykgICAgICAgICAgICAgOiAwMDAxMDIwMzA0MDUwNjA3MDgwOTBhMGIwYzBk MGUwZgogICAgIE1lc3NhZ2UgKE0pICAgICAgICAgOiAwMDAxMDIKICAgICBDYW1lbGxpYS1YQ0JD LU1BQyAgIDogPFRCRD4KICAgICBDYW1lbGxpYS1YQ0JDLU1BQy05NjogPFRCRD4KCiAgICAgVGVz dCBDYXNlICMzICAgICAgICA6IENhbWVsbGlhLVhDQkMtTUFDLTk2IHdpdGggMTYtYnl0ZSBpbnB1 dAogICAgIEtleSAoSykgICAgICAgICAgICAgOiAwMDAxMDIwMzA0MDUwNjA3MDgwOTBhMGIwYzBk MGUwZgogICAgIE1lc3NhZ2UgKE0pICAgICAgICAgOiAwMDEwMjAzMDQwNTA2MDcwODA5MGEwYjBj MGQwZTBmCiAgICAgQ2FtZWxsaWEtWENCQy1NQUMgICA6IDxUQkQ+CiAgICAgQ2FtZWxsaWEtWENC Qy1NQUMtOTY6IDxUQkQ+CgogICAgIFRlc3QgQ2FzZSAjNCAgICAgICAgOiBDYW1lbGxpYS1YQ0JD LU1BQy05NiB3aXRoIDIwLWJ5dGUgaW5wdXQKICAgICBLZXkgKEspICAgICAgICAgICAgIDogMDAw MTAyMDMwNDA1MDYwNzA4MDkwYTBiMGMwZDBlMGYKICAgICBNZXNzYWdlIChNKSAgICAgICAgIDog MDAwMTAyMDMwNDA1MDYwNzA4MDkwYTBiMGMwZDBlMGYxMDExMTIxMwogICAgIENhbWVsbGlhLVhD QkMtTUFDICAgOiA8VEJEPgogICAgIENhbWVsbGlhLVhDQkMtTUFDLTk2OiA8VEJEPgoKICAgICBU ZXN0IENhc2UgIzUgICAgICAgIDogQ2FtZWxsaWEtWENCQy1NQUMtOTYgd2l0aCAzMi1ieXRlIGlu cHV0CiAgICAgS2V5IChLKSAgICAgICAgICAgICA6IDAwMDEwMjAzMDQwNTA2MDcwODA5MGEwYjBj MGQwZTBmCiAgICAgTWVzc2FnZSAoTSkgICAgICAgICA6IDAwMDEwMjAzMDQwNTA2MDcwODA5MGEw YjBjMGQwZTBmMTAxMTEyMTMxNDE1MQogICAgICAgICAgICAgICAgICAgICAgICAgICA2MTcxODE5 MWExYjFjMWQxZTFmCiAgICAgQ2FtZWxsaWEtWENCQy1NQUMgICA6IDxUQkQ+CiAgICAgQ2FtZWxs aWEtWENCQy1NQUMtOTY6IDxUQkQ+CgogICAgIFRlc3QgQ2FzZSAjNiAgICAgICAgOiBDYW1lbGxp YS1YQ0JDLU1BQy05NiB3aXRoIDM0LWJ5dGUgaW5wdXQKICAgICBLZXkgKEspICAgICAgICAgICAg IDogMDAwMTAyMDMwNDA1MDYwNzA4MDkwYTBiMGMwZDBlMGYKICAgICBNZXNzYWdlIChNKSAgICAg ICAgIDogMDAwMTAyMDMwNDA1MDYwNzA4MDkwYTBiMGMwZDBlMGYxMDExMTIxMzE0MTUxCiAgICAg ICAgICAgICAgICAgICAgICAgICAgIDYxNzE4MTkxYTFiMWMxZDFlMWYyMDIxCiAgICAgQ2FtZWxs aWEtWENCQy1NQUMgICA6IDxUQkQ+CiAgICAgQ2FtZWxsaWEtWENCQy1NQUMtOTY6IDxUQkQ+Cgog ICAgIFRlc3QgQ2FzZSAjNyAgICAgICAgOiBDYW1lbGxpYS1YQ0JDLU1BQy05NiB3aXRoIDEwMDAt Ynl0ZSBpbnB1dAogICAgIEtleSAoSykgICAgICAgICAgICAgOiAwMDAxMDIwMzA0MDUwNjA3MDgw OTBhMGIwYzBkMGUwZgogICAgIE1lc3NhZ2UgKE0pICAgICAgICAgOiAwMDAwMDAwMDAwMDAwMDAw MDAwMCAuLi4gMDAwMDAwMDAwMDAwMDAwMDAwMDAKICAgICAgICAgICAgICAgICAgICAgICAgICAg WzEwMDAgYnl0ZXNdCiAgICAgQ2FtZWxsaWEtWENCQy1NQUMgICA6IDxUQkQ+CiAgICAgQ2FtZWxs aWEtWENCQy1NQUMtOTY6IDxUQkQ+CgoKCgoKCgpLYW5ubyAmIEthbmRhICAgICAgICAgIEV4cGly ZXMgU2VwdGVtYmVyIDE5LCAyMDA5ICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1E cmFmdCAgICBUaGUgQ2FtZWxsaWEgWENCQy05NiBhbmQgWENCQy1QUkYtMTI4ICAgICAgIE1hcmNo IDIwMDkKCgozLjIuICBDYW1lbGxpYS1YQ0JDLVBSRi0xMjgKCiAgIFRoaXMgc2VjdGlvbiBjb250 YWlucyB0aHJlZSB0ZXN0IHZlY3RvcnMoVFYpLCB3aGljaCBjYW4gYmUgdXNlZCB0bwogICBjb25m aXJtIHRoYXQgYW4gaW1wbGVtZW50YXRpb24gaGFzIGNvcnJlY3RseSBpbXBsZW1lbnRlZCBDYW1l bGxpYS0KICAgWENCQy1QUkYtMTI4LgoKICAgICAgVGVzdCBDYXNlICMxIDogQ2FtZWxsaWEtWENC Qy1QUkYtMTI4IHdpdGggMjAtYnl0ZSBpbnB1dAogICAgICBLZXkgICAgICAgICAgOiAwMDAxMDIw MzA0MDUwNjA3MDgwOTBhMGIwYzBkMGUwZgogICAgICBLZXkgTGVuZ3RoICAgOiAxNgogICAgICBN ZXNzYWdlICAgICAgOiAwMDAxMDIwMzA0MDUwNjA3MDgwOTBhMGIwYzBkMGUwZjEwMTExMjEzCiAg ICAgIFBSRiBPdXRwdXQgICA6IDxUQkQ+CgogICAgICBUZXN0IENhc2UgIzIgOiBDYW1lbGxpYS1Y Q0JDLVBSRi0xMjggd2l0aCAyMC1ieXRlIGlucHV0CiAgICAgIEtleSAgICAgICAgICA6IDAwMDEw MjAzMDQwNTA2MDcwODA5CiAgICAgIEtleSBMZW5ndGggICA6IDEwCiAgICAgIE1lc3NhZ2UgICAg ICA6IDAwMDEwMjAzMDQwNTA2MDcwODA5MGEwYjBjMGQwZTBmMTAxMTEyMTMKICAgICAgUFJGIE91 dHB1dCAgIDogPFRCRD4KCiAgICAgIFRlc3QgQ2FzZSAjMyA6IENhbWVsbGlhLVhDQkMtUFJGLTEy OCB3aXRoIDIwLWJ5dGUgaW5wdXQKICAgICAgS2V5ICAgICAgICAgIDogMDAwMTAyMDMwNDA1MDYw NzA4MDkwYTBiMGMwZDBlMGZlZGNiCiAgICAgIEtleSBMZW5ndGggICA6IDE4CiAgICAgIE1lc3Nh Z2UgICAgICA6IDAwMDEwMjAzMDQwNTA2MDcwODA5MGEwYjBjMGQwZTBmMTAxMTEyMTMKICAgICAg UFJGIE91dHB1dCAgIDogPFRCRD4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkthbm5vICYg S2FuZGEgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMTksIDIwMDkgICAgICAgICAgICAgICBb UGFnZSA3XQoMCkludGVybmV0LURyYWZ0ICAgIFRoZSBDYW1lbGxpYSBYQ0JDLTk2IGFuZCBYQ0JD LVBSRi0xMjggICAgICAgTWFyY2ggMjAwOQoKCjQuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoK ICAgQXQgdGhlIHRpbWUgb2Ygd3JpdGluZyB0aGlzIGRvY3VtZW50IHRoZXJlIGFyZSBubyBrbm93 biB3ZWFrIGtleXMgZm9yCiAgIENhbWVsbGlhLiAgQW5kIG5vIHNlY3VyaXR5IHByb2JsZW0gaGFz IGJlZW4gZm91bmQgb24gQ2FtZWxsaWEgWzEwXSwKICAgWzExXQoKICAgRm9yIG90aGVyIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zLCBwbGVhc2UgcmVmZXIgdG8gdGhlIHNlY3VyaXR5CiAgIGNvbnNp ZGVyYXRpb25zIG9mIHRoZSBwcmV2aW91cyB1c2Ugb2YgWENCQyBtb2RlIGRvY3VtZW50IGRlc2Ny aWJlZCBpbgogICBbM10gYW5kIFs0XS4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKS2Fubm8gJiBLYW5kYSAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxOSwgMjAw OSAgICAgICAgICAgICAgIFtQYWdlIDhdCgwKSW50ZXJuZXQtRHJhZnQgICAgVGhlIENhbWVsbGlh IFhDQkMtOTYgYW5kIFhDQkMtUFJGLTEyOCAgICAgICBNYXJjaCAyMDA5CgoKNS4gIElBTkEgQ29u c2lkZXJhdGlvbnMKCiAgIElBTkEgaGFzIGFzc2lnbmVkIEFIL0VTUCBBdXRoZW50aWNhdGlvbiBB bGdvcml0aG0gVmFsdWUgPFRCRDI+IGZvcgogICBJS0V2MiBUcmFuc2Zvcm0gVHlwZSAzIChJbnRl Z3JpdHkgQWxnb3JpdGhtKSB0byBDQU1FTExJQS1YQ0JDLU1BQy4KICAgSUFOQSBoYXMgYXNzaWdu ZWQgQUggVHJhbnNmb3JtIElkZW50aWZpZXIgPFRCRDE+IGZvciBJS0V2MiBUcmFuc2Zvcm0KICAg VHlwZSAyIChQc2V1ZG8tUmFuZG9tIEZ1bmN0aW9uKSB0byBBSF9DQU1FTExJQS1YQ0JDLU1BQy4K CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKS2Fubm8gJiBLYW5k YSAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxOSwgMjAwOSAgICAgICAgICAgICAgIFtQYWdl IDldCgwKSW50ZXJuZXQtRHJhZnQgICAgVGhlIENhbWVsbGlhIFhDQkMtOTYgYW5kIFhDQkMtUFJG LTEyOCAgICAgICBNYXJjaCAyMDA5CgoKNi4gIEFja25vd2xlZGdlbWVudHMKCiAgIFRoaXMgZG9j dW1lbnQgdW5hYmFzaGVkbHkgcmVmZXJyZWQgdG8gWzNdIGFuZCBbNF0uCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkthbm5vICYgS2FuZGEgICAgICAgICAg RXhwaXJlcyBTZXB0ZW1iZXIgMTksIDIwMDkgICAgICAgICAgICAgIFtQYWdlIDEwXQoMCkludGVy bmV0LURyYWZ0ICAgIFRoZSBDYW1lbGxpYSBYQ0JDLTk2IGFuZCBYQ0JDLVBSRi0xMjggICAgICAg TWFyY2ggMjAwOQoKCjcuICBSZWZlcmVuY2VzCgo3LjEuICBOb3JtYXRpdmUKCiAgIFsxXSAgIEJy YWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJl bWVudAogICAgICAgICBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LgoKICAg WzJdICAgTWF0c3VpLCBNLiwgTmFrYWppbWEsIEouLCBhbmQgUy4gTW9yaWFpLCAiQSBEZXNjcmlw dGlvbiBvZiB0aGUKICAgICAgICAgQ2FtZWxsaWEgRW5jcnlwdGlvbiBBbGdvcml0aG0iLCBSRkMg MzcxMywgQXByaWwgMjAwNC4KCiAgIFszXSAgIEZyYW5rZWwsIFMuIGFuZCBILiBIZXJiZXJ0LCAi VGhlIEFFUy1YQ0JDLU1BQy05NiBBbGdvcml0aG0gYW5kCiAgICAgICAgIEl0cyBVc2UgV2l0aCBJ UHNlYyIsIFJGQyAzNTY2LCBTZXB0ZW1iZXIgMjAwMy4KCiAgIFs0XSAgIEhvZmZtYW4sIFAuLCAi VGhlIEFFUy1YQ0JDLVBSRi0xMjggQWxnb3JpdGhtIGZvciB0aGUgSW50ZXJuZXQKICAgICAgICAg S2V5IEV4Y2hhbmdlIFByb3RvY29sIChJS0UpIiwgUkZDIDQ0MzQsIEZlYnJ1YXJ5IDIwMDYuCgog ICBbNV0gICBCbGFjaywgSi4gYW5kIFAuIFJvZ2F3YXksICJGYXN0IEVuY3J5cHRpb24gYW5kIEF1 dGhlbnRpY2F0aW9uOgogICAgICAgICBYQ0JDIEVuY3J5cHRpb24gYW5kIFhFQ0IgQXV0aGVudGlj YXRpb24gTW9kZXMiLCBBdWd1c3QgMjAwMSwgPGgKICAgICAgICAgdHRwOi8vY3NyYy5uaXN0Lmdv di9ncm91cHMvU1QvdG9vbGtpdC9CQ00vZG9jdW1lbnRzLwogICAgICAgICBwcm9wb3NlZG1vZGVz L3hjYmMtbWFjL3hjYmMtbWFjLXNwZWMucGRmPi4KCjcuMi4gIEluZm9ybWF0aXZlCgogICBbNl0g ICBLZW50LCBTLiwgIklQIEF1dGhlbnRpY2F0aW9uIEhlYWRlciIsIFJGQyA0MzAyLCBEZWNlbWJl ciAyMDA1LgoKICAgWzddICAgS2VudCwgUy4sICJJUCBFbmNhcHN1bGF0aW5nIFNlY3VyaXR5IFBh eWxvYWQgKEVTUCkiLCBSRkMgNDMwMywKICAgICAgICAgRGVjZW1iZXIgMjAwNS4KCiAgIFs4XSAg IEthdWZtYW4sIEMuLCBIb2ZmbWFuLCBQLiwgYW5kIFAuIEVyb25lbiwgIkludGVybmV0IEtleSBF eGNoYW5nZQogICAgICAgICBQcm90b2NvbDogSUtFdjIiLCBkcmFmdC1ob2ZmbWFuLWlrZXYyYmlz LTAzICh3b3JrIGluIHByb2dyZXNzKSwKICAgICAgICAgRmVicnVhcnkgMjAwOC4KCiAgIFs5XSAg IEthdG8sIEEuLCBNb3JpYWksIFMuLCBhbmQgTS4gS2FuZGEsICJUaGUgQ2FtZWxsaWEgQ2lwaGVy CiAgICAgICAgIEFsZ29yaXRobSBhbmQgSXRzIFVzZSBXaXRoIElQc2VjIiwgUkZDIDQzMTIsIERl Y2VtYmVyIDIwMDUuCgogICBbMTBdICAiVGhlIE5FU1NJRSBwcm9qZWN0IChOZXcgRXVyb3BlYW4g U2NoZW1lcyBmb3IgU2lnbmF0dXJlcywKICAgICAgICAgSW50ZWdyaXR5IGFuZCBFbmNyeXB0aW9u KSIsCiAgICAgICAgIDxodHRwOi8vd3d3LmNvc2ljLmVzYXQua3VsZXV2ZW4uYWMuYmUvbmVzc2ll Lz4uCgogICBbMTFdICBJbmZvcm1hdGlvbi10ZWNobm9sb2d5IFByb21vdGlvbiBBZ2VuY3kgKElQ QSksICJDcnlwdG9ncmFwaHkKICAgICAgICAgUmVzZWFyY2ggYW5kIEV2YWx1YXRpb24gQ29tbWl0 dGVlcyIsCiAgICAgICAgIDxodHRwOi8vd3d3LmlwYS5nby5qcC9zZWN1cml0eS9lbmMvQ1JZUFRS RUMvaW5kZXgtZS5odG1sPi4KCgoKCgoKCgoKS2Fubm8gJiBLYW5kYSAgICAgICAgICBFeHBpcmVz IFNlcHRlbWJlciAxOSwgMjAwOSAgICAgICAgICAgICAgW1BhZ2UgMTFdCgwKSW50ZXJuZXQtRHJh ZnQgICAgVGhlIENhbWVsbGlhIFhDQkMtOTYgYW5kIFhDQkMtUFJGLTEyOCAgICAgICBNYXJjaCAy MDA5CgoKQXV0aG9ycycgQWRkcmVzc2VzCgogICBTYXRvcnUgS2Fubm8KICAgTlRUIFNvZnR3YXJl IENvcnBvcmF0aW9uCgogICBQaG9uZTogKzgxLTQ1LTIxMi03NTc3CiAgIEZheDogICArODEtNDUt MjEyLTk4MDAKICAgRW1haWw6IGthbm5vLXNAcG8ubnR0cy5jby5qcAoKCiAgIE1hc2F5dWtpIEth bmRhCiAgIE5pcHBvbiBUZWxlZ3JhcGggYW5kIFRlbGVwaG9uZSBDb3Jwb3JhdGlvbgoKICAgUGhv bmU6ICs4MS00MjItNTktMzQ1NgogICBGYXg6ICAgKzgxLTQyMi01OS00MDE1CiAgIEVtYWlsOiBr YW5kYS5tYXNheXVraUBsYWIubnR0LmNvLmpwCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKS2Fubm8gJiBLYW5kYSAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxOSwgMjAwOSAg ICAgICAgICAgICAgW1BhZ2UgMTJdCgwKCg== --------_49C05E7AA0C906DF68E8_MULTIPART_MIXED_-- From vijay@wichorus.com Wed Mar 18 11:32:40 2009 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 9263128C1E2 for ; Wed, 18 Mar 2009 11:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, J_CHICKENPOX_31=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 N4+nfiFQkc14 for ; Wed, 18 Mar 2009 11:32:39 -0700 (PDT) Received: from QMTA15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by core3.amsl.com (Postfix) with ESMTP id B762728C1DD for ; Wed, 18 Mar 2009 11:32:39 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA15.emeryville.ca.mail.comcast.net with comcast id UhGl1b0010EPchoAFiZR5C; Wed, 18 Mar 2009 18:33:25 +0000 Received: from [10.166.254.110] ([99.51.129.145]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id UiYV1b00d38Mh0K8MiYoqv; Wed, 18 Mar 2009 18:33:19 +0000 Message-ID: <49C13E38.9000309@wichorus.com> Date: Wed, 18 Mar 2009 11:32:24 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Tero Kivinen , Yaron Sheffer , "Pasi.Eronen@nokia.com" , saddepalli@freescale.com References: <18871.46432.577501.495334@fireball.kivinen.iki.fi> <49B829A9.6090300@wichorus.com> <18872.64682.15892.720908@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F616@il-ex01.ad.checkpoint.com> <1237241498.5668.21.camel@vijay-ipv6-desktop> <18879.30930.703756.58201@fireball.kivinen.iki.fi> In-Reply-To: <18879.30930.703756.58201@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) 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, 18 Mar 2009 18:32:40 -0000 Tero Kivinen wrote: > Vijay Devarapalli writes: >> My proposal is to limit the REDIRECT payload to appear in message #4 (in >> the first IKE_AUTH response), based on the identity presented by the >> client. And leave EAP scenarios out of scope for this document. > > If others feel this is needed, I am willing to accept that solution, > as it should still be fixed defined location, which means testing it > will be simplier. > >> If someone wants the AAA server to redirect the client based on the >> EAP exchange, a separate document could be written. And this >> document can specify that the REDIRECT message can be sent in >> message 10. > > In this case I would rather propose doing the IKE AUTH exchange > completely and then using the INFORMATIONAL exchange to redirect the > client, i.e. if REDIRECT is allowed in IKE_AUTH, only allow it in the > first response IKE_AUTH packet of the exchage, and nowhere else. Agree. Here is the text proposal to address this issue. If the gateway decides to redirect the client during the IKE_AUTH exchange, based on the identity presented by the client in the IKE_AUTH request message, it prevents the creation of a CHILD SA and sends the REDIRECT payload in the IKE_AUTH response. When the client receives the IKE_AUTH response with the REDIRECT payload, it MUST send an empty message as an acknowledgement and delete the IKEv2 SA as described above. Initiator Responder ( VPN GW) --------- ------------------- (IP_I:500 -> IP_R:500) HDR(A,0), SAi1, KEi, Ni, --> N(REDIRECTED_SUPPORTED) (IP_R:500 -> IP_I:500) <-- HDR(A,B), SAr1, KEr, Nr,[CERTREQ] (IP_I:500 -> IP_R:500) HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]AUTH, SAi2, TSi, TSr} --> (IP_R:500 -> IP_I:500) <-- HDR(A,B), SK {IDr, [CERT,] AUTH, N[REDIRECT, IP_R/FQDN_R]} HDR, SK {} --> In case the IKE_AUTH exchange involves EAP authentication as described in Section 2.16 of RFC 4306 [2] or multiple authentication methods as described in RFC 4739 [6], the IKE_AUTH exchange is more complicated. The identity presented by the client in the first IKE_AUTH request might be a temporary one. In addition, the gateway might decide to redirect the client based on the interaction with the the AAA server, when EAP authentication is used or the external authentication server, when multiple authentication methods are used. In such cases, the gateway MUST complete the IKE_AUTH exchange and then use the gateway-initiated redirect mechanism, i.e., an INFORMATIONAL message with the REDIRECT payload, to redirect the client to another gateway. Pasi, Yaron, Srini, does the above work for you? Vijay From vijay@wichorus.com Wed Mar 18 11:36:12 2009 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 DCD4E28C1E4 for ; Wed, 18 Mar 2009 11:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 GbSKEL5qVSRt for ; Wed, 18 Mar 2009 11:36:12 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id E551B28C1DD for ; Wed, 18 Mar 2009 11:36:11 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA05.westchester.pa.mail.comcast.net with comcast id UfCP1b00T0ldTLk55icxl0; Wed, 18 Mar 2009 18:36:57 +0000 Received: from [10.166.254.110] ([99.51.129.145]) by OMTA04.westchester.pa.mail.comcast.net with comcast id UicW1b00738Mh0K3Qicbue; Wed, 18 Mar 2009 18:36:51 +0000 Message-ID: <49C13F28.9010505@wichorus.com> Date: Wed, 18 Mar 2009 11:36:24 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Addepalli Srini-B22160 References: <28BD9D0449D7604C86B766235FA9A8C906B6F9FD@az33exm23.fsl.freescale.net> In-Reply-To: <28BD9D0449D7604C86B766235FA9A8C906B6F9FD@az33exm23.fsl.freescale.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] Behavior of VPN Gateway when Client does not accept/ignores REDIRECT notification 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, 18 Mar 2009 18:36:13 -0000 Addepalli Srini-B22160 wrote: > From the draft, it is not clear on the VPN Responder behavior if > Initiator proceeds with SA establishment even after receiving "REDIRECT" > notification from the VPN Gateway. > > Draft indicates following: > > When the VPN client receives the IKE_SA_INIT response with the > REDIRECT payload, it initiates a new IKE_SA_INIT exchange with the > VPN gateway listed in the REDIRECT payload. The VPN client includes > the IP address of the original VPN gateway that redirected the > client. The IKEv2 exchange then proceeds as normal with the selected > VPN gateway. > > > I believe that VPN gateway should not stop Client proceeding further > with IKE negotiation even after it sends the REDIRECT notification in > response to IKE_SA_INIT message. No. The client must start using the new gateway. Vijay If that is what is intended, it is good > if above text clarifies that further. > > Thanks > Srini > > From vijay@wichorus.com Wed Mar 18 11:40:54 2009 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 79EFF28C1E9 for ; Wed, 18 Mar 2009 11:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 q-ps7ugydSxI for ; Wed, 18 Mar 2009 11:40:53 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 9F19928C1E2 for ; Wed, 18 Mar 2009 11:40:53 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id UdEk1b00K17UAYkA5ihflc; Wed, 18 Mar 2009 18:41:39 +0000 Received: from [10.166.254.110] ([99.51.129.145]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id UihD1b00E38Mh0K8ZihJqv; Wed, 18 Mar 2009 18:41:34 +0000 Message-ID: <49C14043.2050700@wichorus.com> Date: Wed, 18 Mar 2009 11:41:07 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Addepalli Srini-B22160 References: <28BD9D0449D7604C86B766235FA9A8C906B6FA3B@az33exm23.fsl.freescale.net> In-Reply-To: <28BD9D0449D7604C86B766235FA9A8C906B6FA3B@az33exm23.fsl.freescale.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] DoS Attack Possibility? 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, 18 Mar 2009 18:40:54 -0000 Addepalli Srini-B22160 wrote: > REDIRECT notification by the responder upon receiving IKE_SA_INIT might > be exploited by intelligent injection of REDIRECT notifications. In > site-to-site VPN case, it is not difficult for attackers to know IP > addresses of gateways. UDP source port and destination ports are known. > If attacker guesses the Initiator SPI, it is possible to DoS the VPN > Initiator. This problem compounds if Initiator caches the information > from REDIRECT notification. This attack is similar to DNS Poisoning > attack which became famous in 2008. > > If the initiator SPI is random data, then guessing would be nearly > impossible and we don't need to worry about it. I was told that > Initiator SPI was not mandated to be random in IKEv2 specifications > (Though this problem may not be there in IKEv1 as Cookies are expected > to be random - but we are not discussing IKEv1 here in this context). If > that was the case indeed, then I think that we need to have some > mechanism to thwart these kinds of attacks. > > One possible solution would be to send RANDOM data as part of > "REDIRECTION_SUPPORTED" and expect this RANDOM to be seen in "REDIRECT" > notification. Sounds ok to me. Anyone else have comments/opinions on this before I add this to the document? We can have a random 32-bit identifier included in the REDIRECTION_SUPPORTED payload and have the gateway echo this in the REDIRECT payload. Note that this would be applicable only to redirect during the IKE_SA_INIT exchange. Vijay From yaronf@checkpoint.com Wed Mar 18 13:07:07 2009 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 BB98D28C1EA for ; Wed, 18 Mar 2009 13:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.755 X-Spam-Level: X-Spam-Status: No, score=-2.755 tagged_above=-999 required=5 tests=[AWL=-0.156, 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 9x9Vrlgf5UWh for ; Wed, 18 Mar 2009 13:07:06 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 36A5728C0F5 for ; Wed, 18 Mar 2009 13:07:06 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 92CCA2CC006; Wed, 18 Mar 2009 22:07:49 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B30C12CC002; Wed, 18 Mar 2009 22:07:47 +0200 (IST) X-CheckPoint: {49C1533C-0-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n2IK7kXw028433; Wed, 18 Mar 2009 22:07:47 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 18 Mar 2009 22:07:46 +0200 From: Yaron Sheffer To: Vijay Devarapalli , Addepalli Srini-B22160 Date: Wed, 18 Mar 2009 22:07:44 +0200 Thread-Topic: [IPsec] DoS Attack Possibility? Thread-Index: Acmn+S8+nfXKM/nWQHexsl7oZ8DG4gAC0Sag Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D7C5F7@il-ex01.ad.checkpoint.com> References: <28BD9D0449D7604C86B766235FA9A8C906B6FA3B@az33exm23.fsl.freescale.net> <49C14043.2050700@wichorus.com> In-Reply-To: <49C14043.2050700@wichorus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0052_01C9A815.F6994830" MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] DoS Attack Possibility? 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, 18 Mar 2009 20:07:07 -0000 ------=_NextPart_000_0052_01C9A815.F6994830 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I'm not sure in what way this is worse than other potential attacks at this stage, such as sending back an unprotected notification saying that the offered group is unacceptable. This case is different though if the attacker redirects into a legitimate gateway, because things look normal, traffic gets through, but an innocent gateway may get overwhelmed if all other "equivalent" gateways are redirected to it. It may be simpler to echo the nonce Ni back to the initiator as part of the Redirect payload. This would introduce no new state. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Vijay Devarapalli > Sent: Wednesday, March 18, 2009 20:41 > To: Addepalli Srini-B22160 > Cc: IPsecme WG > Subject: Re: [IPsec] DoS Attack Possibility? > > Addepalli Srini-B22160 wrote: > > REDIRECT notification by the responder upon receiving IKE_SA_INIT might > > be exploited by intelligent injection of REDIRECT notifications. In > > site-to-site VPN case, it is not difficult for attackers to know IP > > addresses of gateways. UDP source port and destination ports are known. > > If attacker guesses the Initiator SPI, it is possible to DoS the VPN > > Initiator. This problem compounds if Initiator caches the information > > from REDIRECT notification. This attack is similar to DNS Poisoning > > attack which became famous in 2008. > > > > If the initiator SPI is random data, then guessing would be nearly > > impossible and we don't need to worry about it. I was told that > > Initiator SPI was not mandated to be random in IKEv2 specifications > > (Though this problem may not be there in IKEv1 as Cookies are expected > > to be random - but we are not discussing IKEv1 here in this context). If > > that was the case indeed, then I think that we need to have some > > mechanism to thwart these kinds of attacks. > > > > One possible solution would be to send RANDOM data as part of > > "REDIRECTION_SUPPORTED" and expect this RANDOM to be seen in "REDIRECT" > > notification. > > Sounds ok to me. Anyone else have comments/opinions on this before I add > this to the document? > > We can have a random 32-bit identifier included in the > REDIRECTION_SUPPORTED payload and have the gateway echo this in the > REDIRECT payload. Note that this would be applicable only to redirect > during the IKE_SA_INIT exchange. > > Vijay > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0052_01C9A815.F6994830 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDMxODIwMDc0NFowIwYJKoZIhvcNAQkEMRYEFI0agrz4a7xz kkioPP9esM2QJml7MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA TlD3RsfSQP1QMhF6kIGHSIGfP+E1rkY3OW460nVEs+MPQJBJMuT3HGYYNBQp2ofZGAvhLlk4bGV1 Bb9Ogj6nQMKtcUss9HrPwvEYniY3+5cPdp64eS8V24ozAyY7nrLPllPpazPqIP4nSOIbBCnR0Xvl ht0YK56Mj1DkqtkLxkxfkOnJ7EEM2aB0p3XFSe08Jlx6IEXF7+nMI4EZb38A3p8OBVuQzKtgXX5f EK2dqXv6wSDN78ygg9Wtpf0pPYh/Z9Hr30s6ROqmxO8/ch8nPCvoMfKlgwGWoS/DKxWsqFLKb6A3 UJnmJ2cpfQMYhkEhvi0LAXnHhTg/3kfJPfKVmgAAAAAAAA== ------=_NextPart_000_0052_01C9A815.F6994830-- From yaronf@checkpoint.com Wed Mar 18 13:22:08 2009 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 7994128C205 for ; Wed, 18 Mar 2009 13:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, J_CHICKENPOX_31=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 8sjTGGrSz-U3 for ; Wed, 18 Mar 2009 13:22:07 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A78913A6A6B for ; Wed, 18 Mar 2009 13:22:06 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B5D8D2CC004; Wed, 18 Mar 2009 22:22:50 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id CBC3B2CC001; Wed, 18 Mar 2009 22:22:47 +0200 (IST) X-CheckPoint: {49C156C0-0-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n2IKMlXw001719; Wed, 18 Mar 2009 22:22:47 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 18 Mar 2009 22:22:46 +0200 From: Yaron Sheffer To: Vijay Devarapalli , Tero Kivinen , "Pasi.Eronen@nokia.com" , "saddepalli@freescale.com" Date: Wed, 18 Mar 2009 22:22:45 +0200 Thread-Topic: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) Thread-Index: Acmn+Az9PW8qT7dDQ02vZZXtgrlOmQADbnQQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D7C5F9@il-ex01.ad.checkpoint.com> References: <18871.46432.577501.495334@fireball.kivinen.iki.fi> <49B829A9.6090300@wichorus.com> <18872.64682.15892.720908@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F616@il-ex01.ad.checkpoint.com> <1237241498.5668.21.camel@vijay-ipv6-desktop> <18879.30930.703756.58201@fireball.kivinen.iki.fi> <49C13E38.9000309@wichorus.com> In-Reply-To: <49C13E38.9000309@wichorus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_005F_01C9A818.0F8166F0" MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) 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, 18 Mar 2009 20:22:08 -0000 ------=_NextPart_000_005F_01C9A818.0F8166F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sorry, it doesn't work for me. For a few reasons: - EAP authentication is the primary use case I see for the Redirect mechanism. If anything should be solved well, it's EAP authentication. - The proposal introduces Redirect during IKE_AUTH, which is fine, but then it reintroduces the complexity of a post-IKE_AUTH Informational. So what's the benefit? Why not simply define that Redirect can always be sent as part of the last message of IKE_AUTH, no matter what was the authentication method. - And lastly, I think the empty response following the IKE_AUTH response is redundant. You don't need to acknowledge a response. Thanks, Yaron > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Wednesday, March 18, 2009 20:32 > To: Tero Kivinen; Yaron Sheffer; Pasi.Eronen@nokia.com; > saddepalli@freescale.com > Cc: IPsecme WG > Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft- > ietf-ipsecme-ikev2-redirect-04) > > Tero Kivinen wrote: > > Vijay Devarapalli writes: > >> My proposal is to limit the REDIRECT payload to appear in message #4 > (in > >> the first IKE_AUTH response), based on the identity presented by the > >> client. And leave EAP scenarios out of scope for this document. > > > > If others feel this is needed, I am willing to accept that solution, > > as it should still be fixed defined location, which means testing it > > will be simplier. > > > >> If someone wants the AAA server to redirect the client based on the > >> EAP exchange, a separate document could be written. And this > >> document can specify that the REDIRECT message can be sent in > >> message 10. > > > > In this case I would rather propose doing the IKE AUTH exchange > > completely and then using the INFORMATIONAL exchange to redirect the > > client, i.e. if REDIRECT is allowed in IKE_AUTH, only allow it in the > > first response IKE_AUTH packet of the exchage, and nowhere else. > > Agree. Here is the text proposal to address this issue. > > If the gateway decides to redirect the client during the IKE_AUTH > exchange, based on the identity presented by the client in the > IKE_AUTH request message, it prevents the creation of a CHILD SA and > sends the REDIRECT payload in the IKE_AUTH response. When the client > receives the IKE_AUTH response with the REDIRECT payload, it MUST > send an empty message as an acknowledgement and delete the IKEv2 SA > as described above. > > Initiator Responder ( VPN GW) > --------- ------------------- > > (IP_I:500 -> IP_R:500) > HDR(A,0), SAi1, KEi, Ni, --> > N(REDIRECTED_SUPPORTED) > > (IP_R:500 -> IP_I:500) > <-- HDR(A,B), SAr1, KEr, Nr,[CERTREQ] > > (IP_I:500 -> IP_R:500) > HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] > [IDr,]AUTH, SAi2, TSi, TSr} --> > > (IP_R:500 -> IP_I:500) > <-- HDR(A,B), SK {IDr, [CERT,] AUTH, > N[REDIRECT, IP_R/FQDN_R]} > > HDR, SK {} --> > > In case the IKE_AUTH exchange involves EAP authentication as > described in Section 2.16 of RFC 4306 [2] or multiple authentication > methods as described in RFC 4739 [6], the IKE_AUTH exchange is more > complicated. The identity presented by the client in the first > IKE_AUTH request might be a temporary one. In addition, the gateway > might decide to redirect the client based on the interaction with the > the AAA server, when EAP authentication is used or the external > authentication server, when multiple authentication methods are used. > In such cases, the gateway MUST complete the IKE_AUTH exchange and > then use the gateway-initiated redirect mechanism, i.e., an > INFORMATIONAL message with the REDIRECT payload, to redirect the > client to another gateway. > > Pasi, Yaron, Srini, does the above work for you? > > Vijay > > > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_005F_01C9A818.0F8166F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDMxODIwMjI0NFowIwYJKoZIhvcNAQkEMRYEFPgCjESEDuhu nUD5h5tMm0HxfktCMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA RaRL4+EZZ3kY8dxu3jfisLapcc5Abb+BnPpOp/XrmmFB2a6T1DCPxQKZAbIU8DbLFU8knGojf8BP qfBUr376NdCkGixYMfQxPgYh3ziqE/5rfSavEl3Iqrnk2xFgycXgTEapeonp9/otkQLOiZhBkMDR gzL5qwd+zNc5NCRM7IfCQxWYuZ8zyQU+Sshfyy5VnobBAstqWmeCPYWvjelLcoYADkO7wYjrzgDO SuJvU4KXQYFOnY/qs1ANiLNGZ0+bBTYDZbMOhSasS3IRV/2hw7wN6Uq4ltN8QI0Xys+qKHafX9BI 9FgqyOgVDexnRRud6fnJplYGldgx9dQznDFCIAAAAAAAAA== ------=_NextPart_000_005F_01C9A818.0F8166F0-- From saddepalli@freescale.com Wed Mar 18 13:51:55 2009 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 02A7A28C223 for ; Wed, 18 Mar 2009 13:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 kNRWM7nENwnM for ; Wed, 18 Mar 2009 13:51:54 -0700 (PDT) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id 440D628C0F5 for ; Wed, 18 Mar 2009 13:51:54 -0700 (PDT) Received: from de01smr02.am.mot.com (de01smr02.freescale.net [10.208.0.151]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id n2IKqLfk001637 for ; Wed, 18 Mar 2009 13:52:27 -0700 (MST) Received: from az33exm23.fsl.freescale.net (az33exm23.am.freescale.net [10.64.32.8]) by de01smr02.am.mot.com (8.13.1/8.13.0) with ESMTP id n2IKqK7h025490 for ; Wed, 18 Mar 2009 15:52:20 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Mar 2009 13:52:18 -0700 Message-ID: <28BD9D0449D7604C86B766235FA9A8C906B6FBE2@az33exm23.fsl.freescale.net> In-Reply-To: <49C13F28.9010505@wichorus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavior of VPN Gateway when Client does not accept/ignores REDIRECT notification Thread-Index: Acmn+SbvKmFPcwUbRp+AbD+XidxtFwAEf55A References: <28BD9D0449D7604C86B766235FA9A8C906B6F9FD@az33exm23.fsl.freescale.net> <49C13F28.9010505@wichorus.com> From: "Addepalli Srini-B22160" To: "Vijay Devarapalli" Cc: IPsecme WG Subject: Re: [IPsec] Behavior of VPN Gateway when Client does not accept/ignores REDIRECT notification 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, 18 Mar 2009 20:51:55 -0000 Hi Vijay, Vijay> No. The client must start using the new gateway. I think that MUST is strong word and "SHOULD" is okay. In any case, this clarity should be there in the text I mentioned before. Thanks Srini -----Original Message----- From: Vijay Devarapalli [mailto:vijay@wichorus.com]=20 Sent: Wednesday, March 18, 2009 11:36 AM To: Addepalli Srini-B22160 Cc: IPsecme WG Subject: Re: Behavior of VPN Gateway when Client does not accept/ignores REDIRECT notification Addepalli Srini-B22160 wrote: > From the draft, it is not clear on the VPN Responder behavior if > Initiator proceeds with SA establishment even after receiving "REDIRECT" > notification from the VPN Gateway. >=20 > Draft indicates following: >=20 > When the VPN client receives the IKE_SA_INIT response with the > REDIRECT payload, it initiates a new IKE_SA_INIT exchange with the > VPN gateway listed in the REDIRECT payload. The VPN client includes > the IP address of the original VPN gateway that redirected the > client. The IKEv2 exchange then proceeds as normal with the selected > VPN gateway. =09 >=20 >=20 > I believe that VPN gateway should not stop Client proceeding further > with IKE negotiation even after it sends the REDIRECT notification in > response to IKE_SA_INIT message.=20 No. The client must start using the new gateway. Vijay If that is what is intended, it is good > if above text clarifies that further. >=20 > Thanks > Srini >=20 >=20 From saddepalli@freescale.com Wed Mar 18 14:03:44 2009 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 5D7A23A69E8 for ; Wed, 18 Mar 2009 14:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, J_CHICKENPOX_31=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 2rVC5MKco6Sv for ; Wed, 18 Mar 2009 14:03:43 -0700 (PDT) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id 8149E3A69B0 for ; Wed, 18 Mar 2009 14:03:43 -0700 (PDT) Received: from de01smr01.freescale.net (de01smr01.freescale.net [10.208.0.31]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id n2IL4QVr004865 for ; Wed, 18 Mar 2009 14:04:27 -0700 (MST) Received: from az33exm23.fsl.freescale.net (az33exm23.am.freescale.net [10.64.32.8]) by de01smr01.freescale.net (8.13.1/8.13.0) with ESMTP id n2IL4QfI018295 for ; Wed, 18 Mar 2009 16:04:26 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Mar 2009 14:04:24 -0700 Message-ID: <28BD9D0449D7604C86B766235FA9A8C906B6FBE5@az33exm23.fsl.freescale.net> In-Reply-To: <49C13E38.9000309@wichorus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) Thread-Index: Acmn+BdANX0zNZg9QymtvwpE9ArlzQAFBNew References: <18871.46432.577501.495334@fireball.kivinen.iki.fi> <49B829A9.6090300@wichorus.com> <18872.64682.15892.720908@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F616@il-ex01.ad.checkpoint.com> <1237241498.5668.21.camel@vijay-ipv6-desktop> <18879.30930.703756.58201@fireball.kivinen.iki.fi> <49C13E38.9000309@wichorus.com> From: "Addepalli Srini-B22160" To: "Vijay Devarapalli" , "Tero Kivinen" , "Yaron Sheffer" , Cc: IPsecme WG Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) 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, 18 Mar 2009 21:03:44 -0000 My feel is that REDIRECT in response to IKE_SA_INIT, first response of IKE_AUTH phase (4th message) and Gateway initiated REDIRECT are good enough If there is a need for REDIRECT after EAP, then I would think that it is more required along with EAP_SUCCESS than at the end. If there are two EAP authentication stages, there may be a requirement to redirect the Initiator to some other VPN Router based on result from first EAP authentication. So, my suggestion in regards to EAP is to send the REDIRECT to Initiator along with EAP-SUCCESS payload. Thanks Srini -----Original Message----- From: Vijay Devarapalli [mailto:vijay@wichorus.com]=20 Sent: Wednesday, March 18, 2009 11:32 AM To: Tero Kivinen; Yaron Sheffer; Pasi.Eronen@nokia.com; Addepalli Srini-B22160 Cc: IPsecme WG Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) Tero Kivinen wrote: > Vijay Devarapalli writes: >> My proposal is to limit the REDIRECT payload to appear in message #4 (in >> the first IKE_AUTH response), based on the identity presented by the >> client. And leave EAP scenarios out of scope for this document. >=20 > If others feel this is needed, I am willing to accept that solution, > as it should still be fixed defined location, which means testing it > will be simplier.=20 >=20 >> If someone wants the AAA server to redirect the client based on the >> EAP exchange, a separate document could be written. And this >> document can specify that the REDIRECT message can be sent in >> message 10. >=20 > In this case I would rather propose doing the IKE AUTH exchange > completely and then using the INFORMATIONAL exchange to redirect the > client, i.e. if REDIRECT is allowed in IKE_AUTH, only allow it in the > first response IKE_AUTH packet of the exchage, and nowhere else. Agree. Here is the text proposal to address this issue. If the gateway decides to redirect the client during the IKE_AUTH exchange, based on the identity presented by the client in the IKE_AUTH request message, it prevents the creation of a CHILD SA and sends the REDIRECT payload in the IKE_AUTH response. When the client receives the IKE_AUTH response with the REDIRECT payload, it MUST send an empty message as an acknowledgement and delete the IKEv2 SA as described above. Initiator Responder ( VPN GW) --------- ------------------- (IP_I:500 -> IP_R:500) HDR(A,0), SAi1, KEi, Ni, --> N(REDIRECTED_SUPPORTED) (IP_R:500 -> IP_I:500) <-- HDR(A,B), SAr1, KEr, Nr,[CERTREQ] (IP_I:500 -> IP_R:500) HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]AUTH, SAi2, TSi, TSr} --> (IP_R:500 -> IP_I:500) <-- HDR(A,B), SK {IDr, [CERT,] AUTH, N[REDIRECT, IP_R/FQDN_R]} HDR, SK {} --> In case the IKE_AUTH exchange involves EAP authentication as described in Section 2.16 of RFC 4306 [2] or multiple authentication methods as described in RFC 4739 [6], the IKE_AUTH exchange is more complicated. The identity presented by the client in the first IKE_AUTH request might be a temporary one. In addition, the gateway might decide to redirect the client based on the interaction with the the AAA server, when EAP authentication is used or the external authentication server, when multiple authentication methods are used. In such cases, the gateway MUST complete the IKE_AUTH exchange and then use the gateway-initiated redirect mechanism, i.e., an INFORMATIONAL message with the REDIRECT payload, to redirect the client to another gateway. Pasi, Yaron, Srini, does the above work for you? Vijay From saddepalli@freescale.com Wed Mar 18 15:50:06 2009 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 A4FC43A6AFF for ; Wed, 18 Mar 2009 15:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 bsDHPzA8JbXF for ; Wed, 18 Mar 2009 15:50:05 -0700 (PDT) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id CEDC73A6AE5 for ; Wed, 18 Mar 2009 15:50:05 -0700 (PDT) Received: from az33smr01.freescale.net (az33smr01.freescale.net [10.64.34.199]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id n2IMocbs001283 for ; Wed, 18 Mar 2009 15:50:44 -0700 (MST) Received: from az33exm23.fsl.freescale.net (az33exm23.am.freescale.net [10.64.32.8]) by az33smr01.freescale.net (8.13.1/8.13.0) with ESMTP id n2IMobJx021914 for ; Wed, 18 Mar 2009 17:50:37 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Mar 2009 15:50:36 -0700 Message-ID: <28BD9D0449D7604C86B766235FA9A8C906B6FC16@az33exm23.fsl.freescale.net> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D7C5F7@il-ex01.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] DoS Attack Possibility? Thread-Index: Acmn+S8+nfXKM/nWQHexsl7oZ8DG4gAC0SagAAXanCA= References: <28BD9D0449D7604C86B766235FA9A8C906B6FA3B@az33exm23.fsl.freescale.net> <49C14043.2050700@wichorus.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D7C5F7@il-ex01.ad.checkpoint.com> From: "Addepalli Srini-B22160" To: "Yaron Sheffer" , "Vijay Devarapalli" Cc: IPsecme WG Subject: Re: [IPsec] DoS Attack Possibility? 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, 18 Mar 2009 22:50:06 -0000 Ok. Since Nonce is also randomly generated, it should work fine.=20 Thanks Srini -----Original Message----- From: Yaron Sheffer [mailto:yaronf@checkpoint.com]=20 Sent: Wednesday, March 18, 2009 1:08 PM To: Vijay Devarapalli; Addepalli Srini-B22160 Cc: IPsecme WG Subject: RE: [IPsec] DoS Attack Possibility? Hi, I'm not sure in what way this is worse than other potential attacks at this stage, such as sending back an unprotected notification saying that the offered group is unacceptable. This case is different though if the attacker redirects into a legitimate gateway, because things look normal, traffic gets through, but an innocent gateway may get overwhelmed if all other "equivalent" gateways are redirected to it. It may be simpler to echo the nonce Ni back to the initiator as part of the Redirect payload. This would introduce no new state. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Vijay Devarapalli > Sent: Wednesday, March 18, 2009 20:41 > To: Addepalli Srini-B22160 > Cc: IPsecme WG > Subject: Re: [IPsec] DoS Attack Possibility? >=20 > Addepalli Srini-B22160 wrote: > > REDIRECT notification by the responder upon receiving IKE_SA_INIT might > > be exploited by intelligent injection of REDIRECT notifications. In > > site-to-site VPN case, it is not difficult for attackers to know IP > > addresses of gateways. UDP source port and destination ports are known. > > If attacker guesses the Initiator SPI, it is possible to DoS the VPN > > Initiator. This problem compounds if Initiator caches the information > > from REDIRECT notification. This attack is similar to DNS Poisoning > > attack which became famous in 2008. > > > > If the initiator SPI is random data, then guessing would be nearly > > impossible and we don't need to worry about it. I was told that > > Initiator SPI was not mandated to be random in IKEv2 specifications > > (Though this problem may not be there in IKEv1 as Cookies are expected > > to be random - but we are not discussing IKEv1 here in this context). If > > that was the case indeed, then I think that we need to have some > > mechanism to thwart these kinds of attacks. > > > > One possible solution would be to send RANDOM data as part of > > "REDIRECTION_SUPPORTED" and expect this RANDOM to be seen in "REDIRECT" > > notification. >=20 > Sounds ok to me. Anyone else have comments/opinions on this before I add > this to the document? >=20 > We can have a random 32-bit identifier included in the > REDIRECTION_SUPPORTED payload and have the gateway echo this in the > REDIRECT payload. Note that this would be applicable only to redirect > during the IKE_SA_INIT exchange. >=20 > Vijay > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From kivinen@iki.fi Thu Mar 19 05:05:05 2009 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 AE1DC3A688A for ; Thu, 19 Mar 2009 05:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 huFbIoWTZe0B for ; Thu, 19 Mar 2009 05:05:04 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 7834A3A6814 for ; Thu, 19 Mar 2009 05:05:04 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n2JC5bF4006693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Mar 2009 14:05:37 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n2JC5ZSE004438; Thu, 19 Mar 2009 14:05:35 +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: <18882.13583.245892.979601@fireball.kivinen.iki.fi> Date: Thu, 19 Mar 2009 14:05:35 +0200 From: Tero Kivinen To: Vijay Devarapalli In-Reply-To: <49C13E38.9000309@wichorus.com> References: <18871.46432.577501.495334@fireball.kivinen.iki.fi> <49B829A9.6090300@wichorus.com> <18872.64682.15892.720908@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F616@il-ex01.ad.checkpoint.com> <1237241498.5668.21.camel@vijay-ipv6-desktop> <18879.30930.703756.58201@fireball.kivinen.iki.fi> <49C13E38.9000309@wichorus.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 14 min Cc: IPsecme WG , "Pasi.Eronen@nokia.com" Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) 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, 19 Mar 2009 12:05:05 -0000 Vijay Devarapalli writes: > Agree. Here is the text proposal to address this issue. > > If the gateway decides to redirect the client during the IKE_AUTH > exchange, based on the identity presented by the client in the > IKE_AUTH request message, it prevents the creation of a CHILD SA and > sends the REDIRECT payload in the IKE_AUTH response. When the client > receives the IKE_AUTH response with the REDIRECT payload, it MUST > send an empty message as an acknowledgement and delete the IKEv2 SA > as described above. That empty message as an acknowledgement is completely against the generic IKEv2 exchange model. That is unacceptable. Also the text does not say whether the IKE SA creation succeded or failed when REDIRECT was sent. As REDIRECT is status notification it would indicate that IKE SA succeded, and in your example it must have succeeded, as initiator used it after the IKE_AUTH to send that empty message. I think the correct way to do that is to split REDIRECT to two different notifications, one REDIRECT that is allocated from the NOTIFY MESSAGES - ERROR TYPES range (0-8191) which indicates that the IKE SA creation failed and initiator MUST move to new location. This is the one that should be used in the IKE_SA_INIT and IKE_AUTH phase. Then there would be another status REDIRECT, which is allocated from the NOTIFY MESSAGES - STATUS TYPES. This status REDIRECT would be used in the INFORMATIONAL exchanges, i.e. where it does not cause IKE SA to be deleted when such notify message is received. This whole discussion is putting more and more me back to my original opinion that we should NOT allow redirects during IKE_AUTH. There is reason to do the redirect during IKE_SA_INIT before doing Diffie-Hellman. There is reason to do it after kwowing the identity, but as others has pointed out in that case it should be done only after the identity has been proven. If redirection is done only after identity has been proven, then it can be done as separate INFORMATIONAL exchange after the IKE_AUTH. I do not want REDIRECT to be defined so that it can be sent any time during IKE_AUTH as that exponentially multiple the number of test cases required for IKE_AUTH tests (i.e. test REDIRECT during all the possible half a dozen messages using different authentication methods including multiple authentication etc). -- kivinen@iki.fi From kivinen@iki.fi Thu Mar 19 05:09:08 2009 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 00F8C3A688A for ; Thu, 19 Mar 2009 05:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 0jveSBqq-7-e for ; Thu, 19 Mar 2009 05:09:07 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E43DD3A681C for ; Thu, 19 Mar 2009 05:09:06 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n2JC9mxk010702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Mar 2009 14:09:48 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n2JC9mNA007785; Thu, 19 Mar 2009 14:09:48 +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: <18882.13836.184820.159411@fireball.kivinen.iki.fi> Date: Thu, 19 Mar 2009 14:09:48 +0200 From: Tero Kivinen To: Vijay Devarapalli In-Reply-To: <49C14043.2050700@wichorus.com> References: <28BD9D0449D7604C86B766235FA9A8C906B6FA3B@az33exm23.fsl.freescale.net> <49C14043.2050700@wichorus.com> 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] DoS Attack Possibility? 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, 19 Mar 2009 12:09:08 -0000 Vijay Devarapalli writes: > Sounds ok to me. Anyone else have comments/opinions on this before I add > this to the document? > > We can have a random 32-bit identifier included in the > REDIRECTION_SUPPORTED payload and have the gateway echo this in the > REDIRECT payload. Note that this would be applicable only to redirect > during the IKE_SA_INIT exchange. 32-bits is way too short. If you want cookie better use something that is suitable for cookie, and even better do not limit the size. As there is no data currently in the REDIRECT_SUPPORTED, better to just say that the whole REDIRECT_SUPPORTED payload must be returned as is by the server when it is sending REDIRECT back. You can use similar text RFC4306 has about nonces, saying that they must be t least 128 bits in size, and must be randomly chosen (i.e. the length MUST be between 16 and 256 octects inclusive). -- kivinen@iki.fi From kivinen@iki.fi Thu Mar 19 05:13:15 2009 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 6A3DC3A681C for ; Thu, 19 Mar 2009 05:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 dvGIukCSRgXW for ; Thu, 19 Mar 2009 05:13:14 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 5BBBC3A6774 for ; Thu, 19 Mar 2009 05:13:14 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n2JCDqkW028729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Mar 2009 14:13:52 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n2JCDpd3018369; Thu, 19 Mar 2009 14:13:51 +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: <18882.14079.949938.339619@fireball.kivinen.iki.fi> Date: Thu, 19 Mar 2009 14:13:51 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D7C5F7@il-ex01.ad.checkpoint.com> References: <28BD9D0449D7604C86B766235FA9A8C906B6FA3B@az33exm23.fsl.freescale.net> <49C14043.2050700@wichorus.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D7C5F7@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: IPsecme WG , Vijay Devarapalli Subject: Re: [IPsec] DoS Attack Possibility? 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, 19 Mar 2009 12:13:15 -0000 Yaron Sheffer writes: > I'm not sure in what way this is worse than other potential attacks at this > stage, such as sending back an unprotected notification saying that the > offered group is unacceptable. If attacker sends notification back saying the offered group is unacceptable, it will also indicate new group (which must be part of initiators offer) in the notification payload, and then initiator tries again with that. If that new group is acceptable by the server too, then they create IKE_SA with that group, and as it was acceptable with both it is ok. It might not be the strongest group they supported, but the group is one of the acceptable groups for both ends. For other unauthenticated error emssages the initiator should ignore them, and keep trying until the exchange times out. > This case is different though if the attacker redirects into a legitimate > gateway, because things look normal, traffic gets through, but an innocent > gateway may get overwhelmed if all other "equivalent" gateways are > redirected to it. Yes. > It may be simpler to echo the nonce Ni back to the initiator as part of the > Redirect payload. This would introduce no new state. That would also be good solution, as the nonce is already defined to be random and large enough. -- kivinen@iki.fi From vijay@wichorus.com Thu Mar 19 10:21:51 2009 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 98D1F28C180 for ; Thu, 19 Mar 2009 10:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlRVaVTsrpXY for ; Thu, 19 Mar 2009 10:21:50 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 9D5AC28C17C for ; Thu, 19 Mar 2009 10:21:50 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id UzlZ1b0050x6nqcA75Ndba; Thu, 19 Mar 2009 17:22:37 +0000 Received: from [192.168.20.137] ([216.239.45.19]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id V5Mq1b00b0QpigQ8Y5N02Z; Thu, 19 Mar 2009 17:22:31 +0000 Message-ID: <49C27F2B.3040304@wichorus.com> Date: Thu, 19 Mar 2009 10:21:47 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Tero Kivinen References: <18871.46432.577501.495334@fireball.kivinen.iki.fi> <49B829A9.6090300@wichorus.com> <18872.64682.15892.720908@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F616@il-ex01.ad.checkpoint.com> <1237241498.5668.21.camel@vijay-ipv6-desktop> <18879.30930.703756.58201@fireball.kivinen.iki.fi> <49C13E38.9000309@wichorus.com> <18882.13583.245892.979601@fireball.kivinen.iki.fi> In-Reply-To: <18882.13583.245892.979601@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , "Pasi.Eronen@nokia.com" Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) 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, 19 Mar 2009 17:21:51 -0000 Tero Kivinen wrote: > Vijay Devarapalli writes: >> Agree. Here is the text proposal to address this issue. >> >> If the gateway decides to redirect the client during the IKE_AUTH >> exchange, based on the identity presented by the client in the >> IKE_AUTH request message, it prevents the creation of a CHILD SA and >> sends the REDIRECT payload in the IKE_AUTH response. When the client >> receives the IKE_AUTH response with the REDIRECT payload, it MUST >> send an empty message as an acknowledgement and delete the IKEv2 SA >> as described above. > > That empty message as an acknowledgement is completely against the > generic IKEv2 exchange model. That is unacceptable. Thats an oversight. I combined the IKE_AUTH response with NO_ADDITIONAL_SAs payload and the Informational message with REDIRECT payload, but didn't remove the ack from the client. This is fixed now. > Also the text does not say whether the IKE SA creation succeded or > failed when REDIRECT was sent. As REDIRECT is status notification it > would indicate that IKE SA succeded, and in your example it must have > succeeded, as initiator used it after the IKE_AUTH to send that empty > message. The IKEv2 of course succeeded, otherwise the IKE_AUTH exchange would not have happened. The client needs to delete the IKEv2 SA after receiving the REDIRECT message. > I think the correct way to do that is to split REDIRECT to two > different notifications, one REDIRECT that is allocated from the > NOTIFY MESSAGES - ERROR TYPES range (0-8191) which indicates that the > IKE SA creation failed and initiator MUST move to new location. This > is the one that should be used in the IKE_SA_INIT and IKE_AUTH phase. > Then there would be another status REDIRECT, which is allocated from > the NOTIFY MESSAGES - STATUS TYPES. This status REDIRECT would be used > in the INFORMATIONAL exchanges, i.e. where it does not cause IKE SA to > be deleted when such notify message is received. I think we should keep this simple, assume that the IKEv2 SA does not become invalid because of the REDIRECT message received during the IKE_AUTH exchange and have the client delete the IKEv2 SA. If the REDIRECT is received during the IKE_SA_INIT exchange, then the IKEv2 SA is not created. This is what is described in the document currently. Vijay > This whole discussion is putting more and more me back to my original > opinion that we should NOT allow redirects during IKE_AUTH. > > There is reason to do the redirect during IKE_SA_INIT before doing > Diffie-Hellman. > > There is reason to do it after kwowing the identity, but as others has > pointed out in that case it should be done only after the identity has > been proven. If redirection is done only after identity has been > proven, then it can be done as separate INFORMATIONAL exchange after > the IKE_AUTH. > > I do not want REDIRECT to be defined so that it can be sent any time > during IKE_AUTH as that exponentially multiple the number of test > cases required for IKE_AUTH tests (i.e. test REDIRECT during all the > possible half a dozen messages using different authentication methods > including multiple authentication etc). From vijay@wichorus.com Thu Mar 19 10:25:03 2009 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 CDD5428C117 for ; Thu, 19 Mar 2009 10:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2CdD8JDKA9B for ; Thu, 19 Mar 2009 10:25:03 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id CA2123A69B1 for ; Thu, 19 Mar 2009 10:25:02 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA05.westchester.pa.mail.comcast.net with comcast id Uz8y1b0051HzFnQ555RpPl; Thu, 19 Mar 2009 17:25:49 +0000 Received: from [192.168.20.137] ([216.239.45.19]) by OMTA14.westchester.pa.mail.comcast.net with comcast id V5RN1b00F0QpigQ3a5RTir; Thu, 19 Mar 2009 17:25:44 +0000 Message-ID: <49C27FFE.7040906@wichorus.com> Date: Thu, 19 Mar 2009 10:25:18 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Addepalli Srini-B22160 References: <28BD9D0449D7604C86B766235FA9A8C906B6F9FD@az33exm23.fsl.freescale.net> <49C13F28.9010505@wichorus.com> <28BD9D0449D7604C86B766235FA9A8C906B6FBE2@az33exm23.fsl.freescale.net> In-Reply-To: <28BD9D0449D7604C86B766235FA9A8C906B6FBE2@az33exm23.fsl.freescale.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] Behavior of VPN Gateway when Client does not accept/ignores REDIRECT notification 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, 19 Mar 2009 17:25:03 -0000 Addepalli Srini-B22160 wrote: > Hi Vijay, > > Vijay> No. The client must start using the new gateway. > > I think that MUST is strong word and "SHOULD" is okay. > > In any case, this clarity should be there in the text I mentioned > before. When the REDIRECT is received during the IKE_SA_INIT exchange, the IKEv2 SA is not created. Is it enough if I say, the IKEv2 SA is not created? This implies the client cannot continue using the current gateway. Vijay > > Thanks > Srini > > > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Wednesday, March 18, 2009 11:36 AM > To: Addepalli Srini-B22160 > Cc: IPsecme WG > Subject: Re: Behavior of VPN Gateway when Client does not accept/ignores > REDIRECT notification > > Addepalli Srini-B22160 wrote: >> From the draft, it is not clear on the VPN Responder behavior if >> Initiator proceeds with SA establishment even after receiving > "REDIRECT" >> notification from the VPN Gateway. >> >> Draft indicates following: >> >> When the VPN client receives the IKE_SA_INIT response with the >> REDIRECT payload, it initiates a new IKE_SA_INIT exchange with the >> VPN gateway listed in the REDIRECT payload. The VPN client > includes >> the IP address of the original VPN gateway that redirected the >> client. The IKEv2 exchange then proceeds as normal with the > selected >> VPN gateway. >> >> >> I believe that VPN gateway should not stop Client proceeding further >> with IKE negotiation even after it sends the REDIRECT notification in >> response to IKE_SA_INIT message. > > No. The client must start using the new gateway. > > Vijay > > If that is what is intended, it is good >> if above text clarifies that further. >> >> Thanks >> Srini >> >> > > From saddepalli@freescale.com Thu Mar 19 12:20:03 2009 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 2E2B53A6967 for ; Thu, 19 Mar 2009 12:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 brlmWj842-lf for ; Thu, 19 Mar 2009 12:20:02 -0700 (PDT) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id 17A1E3A68EC for ; Thu, 19 Mar 2009 12:20:02 -0700 (PDT) Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id n2JJKUsC000081 for ; Thu, 19 Mar 2009 12:20:36 -0700 (MST) Received: from az33exm23.fsl.freescale.net (az33exm23.am.freescale.net [10.64.32.8]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id n2JJKTTR004820 for ; Thu, 19 Mar 2009 14:20:30 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Mar 2009 12:20:26 -0700 Message-ID: <28BD9D0449D7604C86B766235FA9A8C906B6FD63@az33exm23.fsl.freescale.net> In-Reply-To: <49C27FFE.7040906@wichorus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Behavior of VPN Gateway when Client does not accept/ignores REDIRECT notification Thread-Index: Acmot8a34+d0zbG9QNaLd6d97mBEAwAD7SGg References: <28BD9D0449D7604C86B766235FA9A8C906B6F9FD@az33exm23.fsl.freescale.net> <49C13F28.9010505@wichorus.com> <28BD9D0449D7604C86B766235FA9A8C906B6FBE2@az33exm23.fsl.freescale.net> <49C27FFE.7040906@wichorus.com> From: "Addepalli Srini-B22160" To: "Vijay Devarapalli" Cc: IPsecme WG Subject: Re: [IPsec] Behavior of VPN Gateway when Client does not accept/ignores REDIRECT notification 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, 19 Mar 2009 19:20:03 -0000 Hi Vijay, That should be fine. Thought it is obvious with this new statement, it is good to extend the description saying that if client indeed wants to connect to the same server again, it can send IKE_SA_INIT message without REDIRECT_SUPPORTED message. Thanks Srini -----Original Message----- From: Vijay Devarapalli [mailto:vijay@wichorus.com]=20 Sent: Thursday, March 19, 2009 10:25 AM To: Addepalli Srini-B22160 Cc: IPsecme WG Subject: Re: Behavior of VPN Gateway when Client does not accept/ignores REDIRECT notification Addepalli Srini-B22160 wrote: > Hi Vijay, >=20 > Vijay> No. The client must start using the new gateway. >=20 > I think that MUST is strong word and "SHOULD" is okay. >=20 > In any case, this clarity should be there in the text I mentioned > before. When the REDIRECT is received during the IKE_SA_INIT exchange, the IKEv2 SA is not created. Is it enough if I say, the IKEv2 SA is not created?=20 This implies the client cannot continue using the current gateway. Vijay >=20 > Thanks > Srini >=20 >=20 >=20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com]=20 > Sent: Wednesday, March 18, 2009 11:36 AM > To: Addepalli Srini-B22160 > Cc: IPsecme WG > Subject: Re: Behavior of VPN Gateway when Client does not accept/ignores > REDIRECT notification >=20 > Addepalli Srini-B22160 wrote: >> From the draft, it is not clear on the VPN Responder behavior if >> Initiator proceeds with SA establishment even after receiving > "REDIRECT" >> notification from the VPN Gateway. >> >> Draft indicates following: >> >> When the VPN client receives the IKE_SA_INIT response with the >> REDIRECT payload, it initiates a new IKE_SA_INIT exchange with the >> VPN gateway listed in the REDIRECT payload. The VPN client > includes >> the IP address of the original VPN gateway that redirected the >> client. The IKEv2 exchange then proceeds as normal with the > selected >> VPN gateway. =09 >> >> >> I believe that VPN gateway should not stop Client proceeding further >> with IKE negotiation even after it sends the REDIRECT notification in >> response to IKE_SA_INIT message.=20 >=20 > No. The client must start using the new gateway. >=20 > Vijay >=20 > If that is what is intended, it is good >> if above text clarifies that further. >> >> Thanks >> Srini >> >> >=20 >=20 From Pasi.Eronen@nokia.com Fri Mar 20 06:21:59 2009 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 A10CE3A6C6B for ; Fri, 20 Mar 2009 06:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 kDJziVzU+8aY for ; Fri, 20 Mar 2009 06:21:58 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 8A8913A6966 for ; Fri, 20 Mar 2009 06:21:58 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2KDMb9H032076; Fri, 20 Mar 2009 15:22:41 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Mar 2009 15:22:41 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Mar 2009 15:22:36 +0200 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 20 Mar 2009 14:22:36 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Fri, 20 Mar 2009 14:22:35 +0100 From: To: Date: Fri, 20 Mar 2009 14:22:35 +0100 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 Thread-Index: AcmihDmso8avLBF+SlScXWvqc2yH+AGyhV6w Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F202D561@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727F1E99700@NOK-EUMSG-01.mgdnok.nokia.com> <49B826A8.80306@wichorus.com> In-Reply-To: <49B826A8.80306@wichorus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Mar 2009 13:22:36.0570 (UTC) FILETIME=[EF6D2FA0:01C9A95E] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 20 Mar 2009 13:21:59 -0000 Vijay Devarapalli wrote: > > Right... but if the client does not have a PAD entry for gw2's IDr, > > then the IKE negotiation will fail. (I guess we're not considering > > updating the PAD based on REDIRECTs.) >=20 > Thats exactly what I am suggesting. :) >=20 > This would be similar to a Mobile IPv6 mobile node creating a PAD > entry for the home agent that it discovers using IETF-standardized > mechanisms. I don't think we should require a Mobile IPv6 mobile > node or a VPN client or a 3GPP client that uses I-WLAN and discovers > a PDG [*] to have PAD entries configured for all the home > agents/gateways/PDGs that it might attach to before hand. Why not? As Tero already commented, this specification could simply assume that if the discovery mechanism creates a PAD entry, it can also create a wildcard PAD entry (that matches e.g. all gateways that have certificate issued by CA X). > (* Apologies for using 3GPP terminology in the above. Pasi knows > what I am talking about. If anyone wants to know more about this, > please let me know. You might regret it later though. :) >=20 > > (BTW, note that "having same IDr" is not exactly the same thing as > > "having same FQDN" -- gw1.example.com and gw2.foobar.example are > > clearly distinct FQDNs from DNS-point-of-view, but they might or > > might not be distinct "principals" from IPsec PAD point of view.) >=20 > If you put the FQDN in the PAD entry, you do have an issue, right? Well... the FQDN in the PAD entry can be a wildcard (but the FQDN sent in DNS query obvious can't). Best regards, Pasi= From Pasi.Eronen@nokia.com Fri Mar 20 06:22:02 2009 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 5DDAF3A6C83 for ; Fri, 20 Mar 2009 06:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.908 X-Spam-Level: X-Spam-Status: No, score=-5.908 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, 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 4iaVrfpjuhm4 for ; Fri, 20 Mar 2009 06:22:01 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 32F2E3A6C7D for ; Fri, 20 Mar 2009 06:22:01 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2KDMeMq013618; Fri, 20 Mar 2009 08:22:45 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Mar 2009 15:22:42 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Mar 2009 15:22:37 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Fri, 20 Mar 2009 14:22:36 +0100 From: To: , Date: Fri, 20 Mar 2009 14:22:35 +0100 Thread-Topic: Issue (resumption): SK_* not necessarily fresh? Thread-Index: Acmm6UqByMXcmB7fShmPeGL56s3AsQAJt2owAI+tjLA= Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F202D562@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727F1FB2805@NOK-EUMSG-01.mgdnok.nokia.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D7C3CD@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D7C3CD@il-ex01.ad.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 X-OriginalArrivalTime: 20 Mar 2009 13:22:37.0257 (UTC) FILETIME=[EFD60390:01C9A95E] X-Nokia-AV: Clean Subject: Re: [IPsec] Issue (resumption): SK_* not necessarily fresh? 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, 20 Mar 2009 13:22:02 -0000 Hi Yaron, Hmm... yes, probably adding a nonce there would solve the freshness issue. Best regards, Pasi=20 > -----Original Message----- > From: ext Yaron Sheffer [mailto:yaronf@checkpoint.com]=20 > Sent: 17 March, 2009 18:03 > To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec@ietf.org > Subject: RE: Issue (resumption): SK_* not necessarily fresh? >=20 > Hi Pasi, >=20 > Thanks for your extensive comments. >=20 > One way to deal with the attack you present here is by adding=20 > a nonce to the > responder's side: >=20 > HDR, Ni, N(TICKET_OPAQUE'), [N+,] SK{...} --> >=20 > <-- HDR, Nr', SK'{Nr, SAr2, [TSi, TSr], ...} >=20 > Where Nr' is the new nonce, SK' depends on the ticket, Ni and Nr'. >=20 > Would that resolve the freshness issue? >=20 > Thanks, > Yaron >=20 > > -----Original Message----- > > From: ipsec-bounces@ietf.org=20 > [mailto:ipsec-bounces@ietf.org] On Behalf Of > > Pasi.Eronen@nokia.com > > Sent: Tuesday, March 17, 2009 12:15 > > To: ipsec@ietf.org > > Subject: [IPsec] Issue (resumption): SK_* not necessarily fresh? > >=20 > > > >=20 > > If an attacker replays a valid IKE_SESSION_RESUME request (and the > > gateway/gateway cluster does not have state to detect=20 > this), then the > > SK_* keys used in the IKE_SESSION_RESUME response will not be fresh > > (since they depend only on the ticket and Ni). > >=20 > > If the IKE_SA uses CBC mode encryption and HMAC for=20 > integrity, that's > > probably not a very big problem. But if the IKE_SA uses CTR, CCM or > > GCM mode, it probably is. > >=20 > > I already pointed out this to the authors in December 2007, but the > > latest draft doesn't seem to say anything about it yet. Back then, > > I argued that the simplest solution to this (and some other > > complexities) is a two-roundtrip-protocol, but if others=20 > think saving > > one RTT is worth the extra complexity, this is one part of=20 > that extra > > complexity that has to be addressed somehow... > >=20 > > BTW, the COOKIE roundtrip in Section 4.3.2 does *not* solve this > > problem; a two-roundtrip version not having this problem would look > > something like this: > >=20 > > HDR(A,0), Ni, N(TICKET_OPAQUE) --> > > <-- HDR(A,B), Nr > > [ calculate SKEYSEED =3D prf(old SK_d, Ni | Nr) ] > > HDR(A,B), SK { AUTH, [CP], SAi2, TSi, TSr, } --> > > [ AUTH =3D prf(SK_pi, ) ] > > <-- HDR(A,B), SK { AUTH, [CP], SAr2, TSi, TSr } > > [ AUTH =3D prf(SK_pr, ) ] > >=20 > > Best regards, > > Pasi > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > >=20 > > Scanned by Check Point Total Security Gateway. > = From Pasi.Eronen@nokia.com Fri Mar 20 06:22:27 2009 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 412AB3A6C6B for ; Fri, 20 Mar 2009 06:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.503 X-Spam-Level: X-Spam-Status: No, score=-4.503 tagged_above=-999 required=5 tests=[AWL=-1.904, 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 xxHn0sgxjeva for ; Fri, 20 Mar 2009 06:22:26 -0700 (PDT) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id 090803A6C8C for ; Fri, 20 Mar 2009 06:22:25 -0700 (PDT) Received: from mgw-mx09.nokia.com ([192.100.105.134]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2KDN6x3016048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 20 Mar 2009 15:23:08 +0200 Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2KDMiwN013958; Fri, 20 Mar 2009 08:23:01 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Mar 2009 15:22:38 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Mar 2009 15:22:33 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Fri, 20 Mar 2009 14:22:32 +0100 From: "Pasi.Eronen@nokia.com" To: Date: Fri, 20 Mar 2009 14:22:31 +0100 Thread-Topic: Issue #17: Checking of the other peer's IKE SPI Thread-Index: AcmiTYsEzz/9hnM8STqbmu9rYEroLAG/lNYA Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F202D55F@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC74@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727F1E9975F@NOK-EUMSG-01.mgdnok.nokia.com> <18871.48349.182611.966945@fireball.kivinen.iki.fi> In-Reply-To: <18871.48349.182611.966945@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 X-OriginalArrivalTime: 20 Mar 2009 13:22:33.0337 (UTC) FILETIME=[ED7FDE90:01C9A95E] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #17: Checking of the other peer's IKE SPI 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, 20 Mar 2009 13:22:27 -0000 Tero Kivinen wrote: > > If it's not an interop issue, and not a security issue, then I'm > > not sure if mandating such check is needed. But are there some=20 > > security implications? >=20 > I agree that there is no real need to mandate such check, but if > IKEv2 tester implementations are requiring such check that will be > de-facto requirement to add such check, as otherwise you will not > pass their tests. >=20 > So for that it is interoperability issue, as you cannot pass their > interoperability tests if you do not check it. So thats why I think > it would be good to say that either it is valid to check only your > own SPI or that you MUST check both spis. Hmm, I see your point -- if even tester implementors have been confused, it certainly would be good to say *something* about this in the specification. (But since this is about interaction with non-compliant implementations, I don't really care which way we choose..) Best regards, Pasi= From Pasi.Eronen@nokia.com Fri Mar 20 06:22:38 2009 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 0BF343A6966 for ; Fri, 20 Mar 2009 06:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.485 X-Spam-Level: X-Spam-Status: No, score=-4.485 tagged_above=-999 required=5 tests=[AWL=-1.886, 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 5YDDasGhkSBp for ; Fri, 20 Mar 2009 06:22:37 -0700 (PDT) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id AAF3B3A6C8F for ; Fri, 20 Mar 2009 06:22:36 -0700 (PDT) Received: from mgw-mx09.nokia.com ([192.100.105.134]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2KDNH4G016112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 20 Mar 2009 15:23:19 +0200 Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2KDMbMZ013596; Fri, 20 Mar 2009 08:23:14 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Mar 2009 15:22:48 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Mar 2009 15:22:44 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Mar 2009 15:22:39 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Fri, 20 Mar 2009 14:22:34 +0100 From: "Pasi.Eronen@nokia.com" To: , , Date: Fri, 20 Mar 2009 14:22:34 +0100 Thread-Topic: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) Thread-Index: Acmm6aajGjdy1BCPQm+n7Pkwxb4YwgACdNHgAJaITxA= Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F202D560@NOK-EUMSG-01.mgdnok.nokia.com> References: <18871.46432.577501.495334@fireball.kivinen.iki.fi> <49B829A9.6090300@wichorus.com> <18872.64682.15892.720908@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F616@il-ex01.ad.checkpoint.com> <1237241498.5668.21.camel@vijay-ipv6-desktop> <18879.30930.703756.58201@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F9F4@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F9F4@il-ex01.ad.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 X-OriginalArrivalTime: 20 Mar 2009 13:22:39.0114 (UTC) FILETIME=[F0F15EA0:01C9A95E] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) 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, 20 Mar 2009 13:22:38 -0000 Hmm -- if the redirect is based on the (real) initiator identity, then I agree that the logical place is the last IKE_AUTH response (in case of EAP, we might not know the real initiator identity before that anyway). But what if the redirect is based on the *responder* identity (the optional IDr payload in the first IKE_AUTH request)?=20 At least 3GPP specs often have multiple responder identities on the same IP address (and use the IDr in IKE_AUTH request to distinguish them). In that case, allowing redirect in the first IKE_AUTH response might make sense. Best regards, Pasi=20 > -----Original Message----- > From: Yaron Sheffer > Sent: 17 March, 2009 13:34 > To: Tero Kivinen; Vijay Devarapalli > Cc: IPsecme WG > Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG=20 > Last Call:draft-ietf-ipsecme-ikev2-redirect-04) >=20 > Hi Tero, Vijay, >=20 > I'm all for restricting Redirect to only one fixed defined > location. But I suggest that this location should be the *last* > message of IKE_AUTH, whether you're using EAP or not. This would be > message #4 in barebones IKE, message #18 in Tero's long example. I > don't think a security protocol should perform operations based on > asserted, unauthenticated identity. >=20 > Thanks, > Yaron >=20 > > -----Original Message----- > > From: Tero Kivinen [mailto:kivinen@iki.fi] > > Sent: Tuesday, March 17, 2009 12:18 > > To: Vijay Devarapalli > > Cc: Yaron Sheffer; IPsecme WG > > Subject: RE: [IPsec] Redirect during IKE_AUTH (was Re: WG=20 > Last Call:draft- > > ietf-ipsecme-ikev2-redirect-04) > >=20 > > Vijay Devarapalli writes: > > > My proposal is to limit the REDIRECT payload to appear in=20 > message #4 (in > > > the first IKE_AUTH response), based on the identity=20 > presented by the > > > client. And leave EAP scenarios out of scope for this document. > >=20 > > If others feel this is needed, I am willing to accept that solution, > > as it should still be fixed defined location, which means testing it > > will be simplier. > >=20 > > > If someone wants the AAA server to redirect the client=20 > based on the > > > EAP exchange, a separate document could be written. And this > > > document can specify that the REDIRECT message can be sent in > > > message 10. > >=20 > > In this case I would rather propose doing the IKE AUTH exchange > > completely and then using the INFORMATIONAL exchange to redirect the > > client, i.e. if REDIRECT is allowed in IKE_AUTH, only allow=20 > it in the > > first response IKE_AUTH packet of the exchage, and nowhere else. > > -- > > kivinen@iki.fi > >=20 > > Scanned by Check Point Total Security Gateway. >=20 From yaronf@checkpoint.com Fri Mar 20 10:55:57 2009 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 AB0F83A6B31 for ; Fri, 20 Mar 2009 10:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[AWL=-0.130, 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 Ml5BP+L13pTq for ; Fri, 20 Mar 2009 10:55:56 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id E24513A6947 for ; Fri, 20 Mar 2009 10:55:55 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 94E212CC003; Fri, 20 Mar 2009 19:56:41 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 34C092CC001; Fri, 20 Mar 2009 19:56:40 +0200 (IST) X-CheckPoint: {49C3D75E-0-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n2KHudXw021401; Fri, 20 Mar 2009 19:56:39 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Fri, 20 Mar 2009 19:56:39 +0200 From: Yaron Sheffer To: "Pasi.Eronen@nokia.com" , "kivinen@iki.fi" , "vijay@wichorus.com" Date: Fri, 20 Mar 2009 19:56:37 +0200 Thread-Topic: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) Thread-Index: Acmm6aajGjdy1BCPQm+n7Pkwxb4YwgACdNHgAJaITxAADakmoA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D7C83A@il-ex01.ad.checkpoint.com> References: <18871.46432.577501.495334@fireball.kivinen.iki.fi> <49B829A9.6090300@wichorus.com> <18872.64682.15892.720908@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F616@il-ex01.ad.checkpoint.com> <1237241498.5668.21.camel@vijay-ipv6-desktop> <18879.30930.703756.58201@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F9F4@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727F202D560@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F202D560@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01C9A995.F9C04B40" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) 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, 20 Mar 2009 17:55:57 -0000 ------=_NextPart_000_0000_01C9A995.F9C04B40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Wait, we're all assuming the Redirect is sent by the responder. In which case I don't understand what is the meaning of redirecting based on IDr. Thanks, Yaron > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Friday, March 20, 2009 15:23 > To: Yaron Sheffer; kivinen@iki.fi; vijay@wichorus.com > Cc: ipsec@ietf.org > Subject: RE: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft- > ietf-ipsecme-ikev2-redirect-04) > > Hmm -- if the redirect is based on the (real) initiator identity, then > I agree that the logical place is the last IKE_AUTH response > (in case of EAP, we might not know the real initiator identity > before that anyway). > > But what if the redirect is based on the *responder* identity (the > optional IDr payload in the first IKE_AUTH request)? > > At least 3GPP specs often have multiple responder identities on the > same IP address (and use the IDr in IKE_AUTH request to distinguish > them). In that case, allowing redirect in the first IKE_AUTH > response might make sense. > > Best regards, > Pasi > > > -----Original Message----- > > From: Yaron Sheffer > > Sent: 17 March, 2009 13:34 > > To: Tero Kivinen; Vijay Devarapalli > > Cc: IPsecme WG > > Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG > > Last Call:draft-ietf-ipsecme-ikev2-redirect-04) > > > > Hi Tero, Vijay, > > > > I'm all for restricting Redirect to only one fixed defined > > location. But I suggest that this location should be the *last* > > message of IKE_AUTH, whether you're using EAP or not. This would be > > message #4 in barebones IKE, message #18 in Tero's long example. I > > don't think a security protocol should perform operations based on > > asserted, unauthenticated identity. > > > > Thanks, > > Yaron > > > > > -----Original Message----- > > > From: Tero Kivinen [mailto:kivinen@iki.fi] > > > Sent: Tuesday, March 17, 2009 12:18 > > > To: Vijay Devarapalli > > > Cc: Yaron Sheffer; IPsecme WG > > > Subject: RE: [IPsec] Redirect during IKE_AUTH (was Re: WG > > Last Call:draft- > > > ietf-ipsecme-ikev2-redirect-04) > > > > > > Vijay Devarapalli writes: > > > > My proposal is to limit the REDIRECT payload to appear in > > message #4 (in > > > > the first IKE_AUTH response), based on the identity > > presented by the > > > > client. And leave EAP scenarios out of scope for this document. > > > > > > If others feel this is needed, I am willing to accept that solution, > > > as it should still be fixed defined location, which means testing it > > > will be simplier. > > > > > > > If someone wants the AAA server to redirect the client > > based on the > > > > EAP exchange, a separate document could be written. And this > > > > document can specify that the REDIRECT message can be sent in > > > > message 10. > > > > > > In this case I would rather propose doing the IKE AUTH exchange > > > completely and then using the INFORMATIONAL exchange to redirect the > > > client, i.e. if REDIRECT is allowed in IKE_AUTH, only allow > > it in the > > > first response IKE_AUTH packet of the exchage, and nowhere else. > > > -- > > > kivinen@iki.fi > > > > > > Scanned by Check Point Total Security Gateway. > > > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0000_01C9A995.F9C04B40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDMyMDE3NTYzNlowIwYJKoZIhvcNAQkEMRYEFE4AU0kfFztV Am6IEzhthmzbDr7wMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA CxLqcN0c0R+yOgdEd/RFeVu+7oCX/VyQSFias/mpdhvjX+yfrA0pwsVKI/hQqoJvoXeqP6z3+/u4 oo78lSdT6PgrNVc6P/cMl85g9j4HMGQQfOMB+O3bRlC9N6Ie6w+G8b79cSxRJeywiblouVIx/Q2T qspgNRFX5MTHwPildrwd88S+YvCB2G41nI29c+iASkhxNc9ZDdUswkgOk625rjuaQ8I4NeTobVzG pt8jFN0E9/8JmtwnbDX1HAE4TwqrQ6L0XipVbmLGC4YXj8jQ+c5FZ0BW5UdAFsNvRne5xQqRaH/g MdG4nk76L5g5liIqV5b51+67XWz1IgHjfClvpAAAAAAAAA== ------=_NextPart_000_0000_01C9A995.F9C04B40-- From ynir@checkpoint.com Fri Mar 20 12:01:02 2009 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 1C28128C27F for ; Fri, 20 Mar 2009 12:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 zEughPyjiZID for ; Fri, 20 Mar 2009 12:01:01 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 581AF28C291 for ; Fri, 20 Mar 2009 12:00:52 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 26E0F2CC004; Fri, 20 Mar 2009 21:01:38 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 9E93F2CC002; Fri, 20 Mar 2009 21:01:35 +0200 (IST) X-CheckPoint: {49C3E694-0-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n2KJ1YXw005850; Fri, 20 Mar 2009 21:01:35 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Fri, 20 Mar 2009 21:01:34 +0200 From: Yoav Nir To: Yaron Sheffer , "Pasi.Eronen@nokia.com" , "kivinen@iki.fi" , "vijay@wichorus.com" Date: Fri, 20 Mar 2009 20:59:02 +0200 Thread-Topic: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) Thread-Index: Acmm6aajGjdy1BCPQm+n7Pkwxb4YwgACdNHgAJaITxAADakmoAACa8gI Message-ID: <9FB7C7CE79B84449B52622B506C78036133291CB73@il-ex01.ad.checkpoint.com> References: <18871.46432.577501.495334@fireball.kivinen.iki.fi> <49B829A9.6090300@wichorus.com> <18872.64682.15892.720908@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F616@il-ex01.ad.checkpoint.com> <1237241498.5668.21.camel@vijay-ipv6-desktop> <18879.30930.703756.58201@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F9F4@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727F202D560@NOK-EUMSG-01.mgdnok.nokia.com>, <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D7C83A@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D7C83A@il-ex01.ad.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 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04) 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, 20 Mar 2009 19:01:02 -0000 An Initiator MAY send an IDr in the IKE_AUTH request, to tell the peer whic= h of its multiple identities you want to talk to. The 3GPP people like that= functionality. It makes sense for there to be one gateway, you tell it which identity you'= re looking for, and then it redirects you to the proper gateway for that id= entity. In that case, it makes no sense to authenticate to that "master" ga= teway (presumably with EAP-SIM or EAP-AKA) ________________________________________ From: ipsec-bounces@ietf.org [ipsec-bounces@ietf.org] On Behalf Of Yaron Sh= effer [yaronf@checkpoint.com] Sent: Friday, March 20, 2009 19:56 To: Pasi.Eronen@nokia.com; kivinen@iki.fi; vijay@wichorus.com Cc: ipsec@ietf.org Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:d= raft-ietf-ipsecme-ikev2-redirect-04) Wait, we're all assuming the Redirect is sent by the responder. In which case I don't understand what is the meaning of redirecting based on IDr. Thanks, Yaron > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Friday, March 20, 2009 15:23 > To: Yaron Sheffer; kivinen@iki.fi; vijay@wichorus.com > Cc: ipsec@ietf.org > Subject: RE: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft= - > ietf-ipsecme-ikev2-redirect-04) > > Hmm -- if the redirect is based on the (real) initiator identity, then > I agree that the logical place is the last IKE_AUTH response > (in case of EAP, we might not know the real initiator identity > before that anyway). > > But what if the redirect is based on the *responder* identity (the > optional IDr payload in the first IKE_AUTH request)? > > At least 3GPP specs often have multiple responder identities on the > same IP address (and use the IDr in IKE_AUTH request to distinguish > them). In that case, allowing redirect in the first IKE_AUTH > response might make sense. > > Best regards, > Pasi > > > -----Original Message----- > > From: Yaron Sheffer > > Sent: 17 March, 2009 13:34 > > To: Tero Kivinen; Vijay Devarapalli > > Cc: IPsecme WG > > Subject: Re: [IPsec] Redirect during IKE_AUTH (was Re: WG > > Last Call:draft-ietf-ipsecme-ikev2-redirect-04) > > > > Hi Tero, Vijay, > > > > I'm all for restricting Redirect to only one fixed defined > > location. But I suggest that this location should be the *last* > > message of IKE_AUTH, whether you're using EAP or not. This would be > > message #4 in barebones IKE, message #18 in Tero's long example. I > > don't think a security protocol should perform operations based on > > asserted, unauthenticated identity. > > > > Thanks, > > Yaron > > > > > -----Original Message----- > > > From: Tero Kivinen [mailto:kivinen@iki.fi] > > > Sent: Tuesday, March 17, 2009 12:18 > > > To: Vijay Devarapalli > > > Cc: Yaron Sheffer; IPsecme WG > > > Subject: RE: [IPsec] Redirect during IKE_AUTH (was Re: WG > > Last Call:draft- > > > ietf-ipsecme-ikev2-redirect-04) > > > > > > Vijay Devarapalli writes: > > > > My proposal is to limit the REDIRECT payload to appear in > > message #4 (in > > > > the first IKE_AUTH response), based on the identity > > presented by the > > > > client. And leave EAP scenarios out of scope for this document. > > > > > > If others feel this is needed, I am willing to accept that solution, > > > as it should still be fixed defined location, which means testing it > > > will be simplier. > > > > > > > If someone wants the AAA server to redirect the client > > based on the > > > > EAP exchange, a separate document could be written. And this > > > > document can specify that the REDIRECT message can be sent in > > > > message 10. > > > > > > In this case I would rather propose doing the IKE AUTH exchange > > > completely and then using the INFORMATIONAL exchange to redirect the > > > client, i.e. if REDIRECT is allowed in IKE_AUTH, only allow > > it in the > > > first response IKE_AUTH packet of the exchage, and nowhere else. > > > -- > > > kivinen@iki.fi > > > > > > Scanned by Check Point Total Security Gateway. > > > > Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway. Email secured by Check Point From Pasi.Eronen@nokia.com Sat Mar 21 11:34:38 2009 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 D7D063A68D3 for ; Sat, 21 Mar 2009 11:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 8ND1yjO8Tarz for ; Sat, 21 Mar 2009 11:34:38 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 855153A681F for ; Sat, 21 Mar 2009 11:34:36 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2LIZGCx011126; Sat, 21 Mar 2009 20:35:17 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 21 Mar 2009 20:35:17 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 21 Mar 2009 20:35:17 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Sat, 21 Mar 2009 19:35:16 +0100 From: To: , Date: Sat, 21 Mar 2009 19:35:14 +0100 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 Thread-Index: AcmQG11xz3Y00zEpSza195DYpuB4qgLVe3mQAWVyzAAATYAZgAAAjSawAcMBriA= Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F2071BED@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727EA3FC7B4@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727F1E99700@NOK-EUMSG-01.mgdnok.nokia.com> <9FB7C7CE79B84449B52622B506C78036133299F197@il-ex01.ad.checkpoint.com> In-Reply-To: <9FB7C7CE79B84449B52622B506C78036133299F197@il-ex01.ad.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 X-OriginalArrivalTime: 21 Mar 2009 18:35:17.0238 (UTC) FILETIME=[C811B160:01C9AA53] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 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, 21 Mar 2009 18:34:38 -0000 Yoav Nir wrote: > If the redirect-to gateway is in the PAD, but either does not > protect the same networks at all, or has a partial overlap in > protected networks, then we have a problem, because if the client is > setting up a child SA in order to reach host A, protected by gw1 but > not by gw2, then it's not clear what selectors should be used with > gw2, and whether the whole exercise has any value. >=20 > Perhaps instead of requiring "having the same Idr" we need to > require "having the same SPD entries", except maybe SPDs that cover > the gateways themselves. Hmm -- something along these lines might work; but should it be "having same Child SA Authorization Data in the PAD"? Best regards, Pasi= From root@core3.amsl.com Mon Mar 23 19:45:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6BADC28C0E5; Mon, 23 Mar 2009 19:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090324024501.6BADC28C0E5@core3.amsl.com> Date: Mon, 23 Mar 2009 19:45:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-06.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: Tue, 24 Mar 2009 02:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Redirect Mechanism for IKEv2 Author(s) : V. Devarapalli, K. Weniger Filename : draft-ietf-ipsecme-ikev2-redirect-06.txt Pages : 12 Date : 2009-03-23 IKEv2 is a protocol for setting up VPN tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. Currently there is no standard mechanism specified that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway. This document proposes a redirect mechanism for IKEv2. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-redirect-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-redirect-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-23193632.I-D@ietf.org> --NextPart-- From vijay@wichorus.com Mon Mar 23 20:01:40 2009 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 DBBB23A682D for ; Mon, 23 Mar 2009 20:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 qDjIBUwVywQY for ; Mon, 23 Mar 2009 20:01:40 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 051183A6836 for ; Mon, 23 Mar 2009 20:01:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Mar 2009 23:02:28 -0400 Message-ID: In-Reply-To: <20090324024501.6BADC28C0E5@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-06.txt Thread-Index: AcmsKt1jhANH5QkuTweTH68lL7xOhgAAaP2A References: <20090324024501.6BADC28C0E5@core3.amsl.com> From: "Vijay Devarapalli" To: Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-06.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: Tue, 24 Mar 2009 03:01:40 -0000 Hello, I submitted a revised document addressing some of the issues that we have already agreed upon. There are still two open issues 1. When to send to the REDIRECT payload when EAP or multiple authentications are used 2. REDIRECT message and the corresponding PAD entries. The issue is about whether the new gateway should already be in the PAD or a new PAD entry is created for the new gateway on the client. Hopefully we conclude on these two issues this week. Vijay > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, March 23, 2009 7:45 PM > To: i-d-announce@ietf.org > Cc: ipsec@ietf.org > Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-06.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and=20 > Extensions Working Group of the IETF. >=20 >=20 > Title : Redirect Mechanism for IKEv2 > Author(s) : V. Devarapalli, K. Weniger > Filename : draft-ietf-ipsecme-ikev2-redirect-06.txt > Pages : 12 > Date : 2009-03-23 >=20 > IKEv2 is a protocol for setting up VPN tunnels from a remote location > to a gateway so that the VPN client can access services in the > network behind the gateway. Currently there is no standard mechanism > specified that allows an overloaded VPN gateway or a VPN gateway that > is being shut down for maintenance to redirect the VPN client to > attach to another gateway. This document proposes a redirect > mechanism for IKEv2. The proposed mechanism can also be used in > Mobile IPv6 to enable the home agent to redirect the mobile node to > another home agent. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-r > edirect-06.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 From yaronf@checkpoint.com Tue Mar 24 10:39:03 2009 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 0BB8428C158 for ; Tue, 24 Mar 2009 10:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[AWL=-0.124, 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 pn8RIAUQhwNo for ; Tue, 24 Mar 2009 10:39:00 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 39EB628C143 for ; Tue, 24 Mar 2009 10:38:59 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 946122CC004; Tue, 24 Mar 2009 19:39:49 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 3DD2E2CC001 for ; Tue, 24 Mar 2009 19:38:44 +0200 (IST) X-CheckPoint: {49C918E1-0-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n2OHchXw024339 for ; Tue, 24 Mar 2009 19:38:43 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 24 Mar 2009 19:38:43 +0200 From: Yaron Sheffer To: IPsecme WG Date: Tue, 24 Mar 2009 19:38:39 +0200 Thread-Topic: Minor comments on draft-ietf-ipsecme-traffic-visibility-01 Thread-Index: Acmsp13ytCvK+zerSfSKSjJ45LH42A== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D7CD28@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_015F_01C9AC6C.B19AFDE0" MIME-Version: 1.0 Subject: [IPsec] Minor comments on draft-ietf-ipsecme-traffic-visibility-01 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, 24 Mar 2009 17:39:03 -0000 ------=_NextPart_000_015F_01C9AC6C.B19AFDE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0160_01C9AC6C.B19AFDE0" ------=_NextPart_001_0160_01C9AC6C.B19AFDE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit - Sec. 2.2 title: remove the word "of". - IANA considerations: please be more explicit regarding the specific IANA registries. Also, Sec. 2.3 should say "TBD by IANA". - Flags/version field: I believe this field is neither encrypted nor integrity-protected. If this is the case, please say so, so that the flag field is not used for security-sensitive information. Also, you need to say if the recipient should ignore or drop unknown version numbers. Thanks, Yaron ------=_NextPart_001_0160_01C9AC6C.B19AFDE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

-          Sec. 2.2 = title: remove the word “of”.

-          IANA considerations: please be more explicit regarding the specific IANA = registries. Also, Sec. 2.3 should say “TBD by = IANA”.

-          Flags/version field: I believe this field is neither encrypted nor = integrity-protected. If this is the case, please say so, so that the flag field is not used for security-sensitive information. Also, you need to say if the recipient = should ignore or drop unknown version = numbers.

 

Thanks,

         =    Yaron

------=_NextPart_001_0160_01C9AC6C.B19AFDE0-- ------=_NextPart_000_015F_01C9AC6C.B19AFDE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDMyNDE3MzgzOVowIwYJKoZIhvcNAQkEMRYEFEi5Lj2v7JZf STrRlc4HCdbzkIVbMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA r+DRuJ3gU/F2x28DdCiJ0Q+l3PGyovlW0aFocuO53G1G9jDbDYYH09YpzO8MulwACovJfDLrufVP q+vUT0ZO0rMmrYCrms1TXiJTQh3h3Qm6Skao+8wlvghTNrG3R/jl1yQ9cGVrlTdAYunLPPYSMiVP B90dUJemkKiVQieseCmyGD2cUnsGexllei8f7T1NrI9M1I3UopsXD5TOMIr92CeyxbLScjJvRiu9 5Pga8K9grmpmWBxJUVICnzvbFSUNPyh2bneOEeL2gcWWw/THphjBehmdJttXy7pgFFhwhqHu3VFN w1L6OEzPp6VXiLBv03ejXZlhyj12eOz7JexmsQAAAAAAAA== ------=_NextPart_000_015F_01C9AC6C.B19AFDE0-- From meyerchr@us.ibm.com Tue Mar 24 13:22:21 2009 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 173AE28C10C for ; Tue, 24 Mar 2009 13:22:21 -0700 (PDT) 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 C4rhbFoA-L1O for ; Tue, 24 Mar 2009 13:22:20 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id 2A3153A6C49 for ; Tue, 24 Mar 2009 13:22:20 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e37.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n2OKMiKW018732 for ; Tue, 24 Mar 2009 14:22:44 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2OKNAkn135466 for ; Tue, 24 Mar 2009 14:23:10 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2OKNAIe023468 for ; Tue, 24 Mar 2009 14:23:10 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n2OKNAmO023458 for ; Tue, 24 Mar 2009 14:23:10 -0600 To: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Christopher Meyer Message-ID: Date: Tue, 24 Mar 2009 16:23:09 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 8.5|December 05, 2008) at 03/24/2009 14:23:10, Serialize complete at 03/24/2009 14:23:10 Content-Type: multipart/alternative; boundary="=_alternative 006FA54F85257583_=" Subject: [IPsec] Hash/URL payload handling 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, 24 Mar 2009 20:22:21 -0000 This is a multipart message in MIME format. --=_alternative 006FA54F85257583_= Content-Type: text/plain; charset="US-ASCII" Section 3.6 of RFC 4306 describes the "Hash and URL" form of certificate payloads, including the following text: Implementations MUST be capable of being configured to send and accept up to four X.509 certificates in support of authentication, and also MUST be capable of being configured to send and accept the first two Hash and URL formats (with HTTP URLs). Can I read "HTTP" literally? In other words, is it safe to assume that IKE implementations are not expected to also support HTTPS URLs here as well? Given the public nature of the content to be retrieved, it seems logical that straight HTTP is sufficient, but I'd like to verify the assumption. Thanks, Chris Meyer --=_alternative 006FA54F85257583_= Content-Type: text/html; charset="US-ASCII"
Section 3.6 of RFC 4306 describes the "Hash and URL" form of certificate payloads, including the following text:

   Implementations MUST be capable of being configured to send and
   accept up to four X.509 certificates in support of authentication,
   and also MUST be capable of being configured to send and accept the
   first two Hash and URL formats (with HTTP URLs).  

Can I read "HTTP" literally?  In other words, is it safe to assume that IKE implementations are not expected to also support HTTPS URLs here as well?   Given the public nature of the content to be retrieved, it seems logical that straight HTTP is sufficient, but I'd like to verify the assumption.

Thanks,

Chris Meyer --=_alternative 006FA54F85257583_=-- From paul.hoffman@vpnc.org Tue Mar 24 14:48:49 2009 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 3CC9D28C1F2 for ; Tue, 24 Mar 2009 14:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRxguyCvaust for ; Tue, 24 Mar 2009 14:48:48 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0B7B128C2FA for ; Tue, 24 Mar 2009 14:48:43 -0700 (PDT) Received: from [130.129.17.206] (dhcp-11ce.meeting.ietf.org [130.129.17.206]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OLnU49038884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 14:49:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 24 Mar 2009 14:49:26 -0700 To: Christopher Meyer , From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Hash/URL payload handling 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, 24 Mar 2009 21:48:49 -0000 At 4:23 PM -0400 3/24/09, Christopher Meyer wrote: >Section 3.6 of RFC 4306 describes the "Hash and URL" form of certificate payloads, including the following text: > > Implementations MUST be capable of being configured to send and > accept up to four X.509 certificates in support of authentication, > and also MUST be capable of being configured to send and accept the > first two Hash and URL formats (with HTTP URLs). > >Can I read "HTTP" literally? In other words, is it safe to assume that IKE implementations are not expected to also support HTTPS URLs here as well? Correct. \ --Paul Hoffman, Director --VPN Consortium From pubs.hegde@gmail.com Wed Mar 25 03:56:43 2009 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 DAA453A69E5 for ; Wed, 25 Mar 2009 03:56:43 -0700 (PDT) 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 f-gRoDfttAdo for ; Wed, 25 Mar 2009 03:56:43 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 1AD3B3A6822 for ; Wed, 25 Mar 2009 03:56:43 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so3882089wfg.31 for ; Wed, 25 Mar 2009 03:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=iYpL/ZKD74NPQxcqDBnicQzF/VVIQxcgp6NboHWT4yQ=; b=q+woKBwWi8RQ+1wJhVdX1cPmb5zTh+6AWtAOr7BKhrbItsNSlbXHtiRTLtUdbmgKlD /FnthoOl6xaf2sBtgeOqsX9DKHKmPLiiEOdLZr7U1Ifukh36+6zwMkpxxu70OJMSCACJ q53yX6RmLFMJWuei3MSb0Ri7b+lBYL/lJheGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=oaaYVUusatG6lOFmfQ6xJJ4PZrGTUCmj9WieW8s7b2N6LZY2IQbOud3+0yvshG1fvd PUnW7vyg0ilY/OvWC+hiQvAC8dwUh2iZhZlzFWnDjxuoQdl/3Cfyrcg+HYltE7xJ3uJZ SyQc4f343HADoM1/s+Zlc+j1v2IfThi0+TM1k= MIME-Version: 1.0 Received: by 10.142.214.11 with SMTP id m11mr3878464wfg.22.1237978655412; Wed, 25 Mar 2009 03:57:35 -0700 (PDT) Date: Wed, 25 Mar 2009 16:27:35 +0530 Message-ID: <673ac0640903250357w3dcdfb13y8ad2c3f7e38402e4@mail.gmail.com> From: Prabhat Hegde To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=000e0cd2e61cfed9d40465ef5d3b Subject: [IPsec] is there any proposed solution to solve the anti-replay problem for IPsec pkts when subject to QOS classification 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, 25 Mar 2009 10:56:43 -0000 --000e0cd2e61cfed9d40465ef5d3b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, In case we do QOS re-ordering (caused due to shaping & queueing) for traffic classes after encryption, the encrypted pkts get re-ordered thus changing the order of sequence numbers. At the receiving end, such out-of-order pkts are droped by IPsec since they do not fall under the anit-replay window range. Is there any proposed solution/draft which caters to this problem? If yes, it would be great if someone can point me to it. -- With regards, Prabhat --000e0cd2e61cfed9d40465ef5d3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
=A0=A0=A0=A0=A0 In case we do QOS re-ordering (caused due to shaping= & queueing) for traffic classes after encryption, the encrypted pkts g= et re-ordered thus changing the order of sequence numbers. At the receiving= end, such out-of-order pkts are droped by IPsec since they do not fall und= er the anit-replay window range.
=A0=A0=A0=A0=A0=A0=A0 Is there any proposed solution/draft which caters to = this problem? If yes, it would be great if someone can point me to it.

--
With regards,
Prabhat
--000e0cd2e61cfed9d40465ef5d3b-- From ynir@checkpoint.com Wed Mar 25 04:05:54 2009 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 E72E13A6822 for ; Wed, 25 Mar 2009 04:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, 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 5HxYm6IjEQnS for ; Wed, 25 Mar 2009 04:05:54 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id AFBCD3A679F for ; Wed, 25 Mar 2009 04:05:53 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 19D2230C001; Wed, 25 Mar 2009 13:06:45 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id C715F2CC001; Wed, 25 Mar 2009 13:06:43 +0200 (IST) X-CheckPoint: {49CA0E73-0-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n2PB6gXw018507; Wed, 25 Mar 2009 13:06:43 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 25 Mar 2009 13:06:42 +0200 From: Yoav Nir To: Prabhat Hegde , "ipsec@ietf.org" Date: Wed, 25 Mar 2009 13:07:19 +0200 Thread-Topic: [IPsec] is there any proposed solution to solve the anti-replay problem for IPsec pkts when subject to QOS classification Thread-Index: AcmtOIdHJ5rnK0pTTBKTcXqj+KymEwAAS8fw Message-ID: <9FB7C7CE79B84449B52622B506C780361332A133B6@il-ex01.ad.checkpoint.com> References: <673ac0640903250357w3dcdfb13y8ad2c3f7e38402e4@mail.gmail.com> In-Reply-To: <673ac0640903250357w3dcdfb13y8ad2c3f7e38402e4@mail.gmail.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_9FB7C7CE79B84449B52622B506C780361332A133B6ilex01adcheck_" MIME-Version: 1.0 Subject: Re: [IPsec] is there any proposed solution to solve the anti-replay problem for IPsec pkts when subject to QOS classification 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, 25 Mar 2009 11:05:55 -0000 --_000_9FB7C7CE79B84449B52622B506C780361332A133B6ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RFC 4306 specifically requires implementations to support multiple parallel= child SAs. If you use a different SA for each QoS class, you should not have problems = with the replay window ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of P= rabhat Hegde Sent: Wednesday, March 25, 2009 12:58 PM To: ipsec@ietf.org Subject: [IPsec] is there any proposed solution to solve the anti-replay pr= oblem for IPsec pkts when subject to QOS classification Hi, In case we do QOS re-ordering (caused due to shaping & queueing) for = traffic classes after encryption, the encrypted pkts get re-ordered thus ch= anging the order of sequence numbers. At the receiving end, such out-of-ord= er pkts are droped by IPsec since they do not fall under the anit-replay wi= ndow range. Is there any proposed solution/draft which caters to this problem? = If yes, it would be great if someone can point me to it. -- With regards, Prabhat =0D=0A Email secured by Check Point=0D=0A --_000_9FB7C7CE79B84449B52622B506C780361332A133B6ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
RFC 4306 specifically requires implementations to sup= port=20 multiple parallel child SAs.
 
If you use a different SA for each QoS class, you sho= uld not=20 have problems with the replay window

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Prabhat=20 Hegde
Sent: Wednesday, March 25, 2009 12:58 PM
To:=20 ipsec@ietf.org
Subject: [IPsec] is there any proposed solution = to=20 solve the anti-replay problem for IPsec pkts when subject to QOS=20 classification

Hi,
      In case we do QOS re-ord= ering=20 (caused due to shaping & queueing) for traffic classes after encrypti= on,=20 the encrypted pkts get re-ordered thus changing the order of sequence num= bers.=20 At the receiving end, such out-of-order pkts are droped by IPsec since th= ey do=20 not fall under the anit-replay window=20 range.
        Is there any propose= d=20 solution/draft which caters to this problem? If yes, it would be great if= =20 someone can point me to it.

--
With=20 regards,
Prabhat


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_9FB7C7CE79B84449B52622B506C780361332A133B6ilex01adcheck_-- From Francis.Dupont@fdupont.fr Wed Mar 25 07:33:11 2009 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 4997228C107 for ; Wed, 25 Mar 2009 07:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 5VG+xJqDNvxl for ; Wed, 25 Mar 2009 07:33:10 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 5AB2F28C0CF for ; Wed, 25 Mar 2009 07:33:10 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n2PEY12N028413; Wed, 25 Mar 2009 15:34:01 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200903251434.n2PEY12N028413@givry.fdupont.fr> From: Francis Dupont To: Prabhat Hegde In-reply-to: Your message of Wed, 25 Mar 2009 16:27:35 +0530. <673ac0640903250357w3dcdfb13y8ad2c3f7e38402e4@mail.gmail.com> Date: Wed, 25 Mar 2009 15:34:01 +0100 Sender: Francis.Dupont@fdupont.fr Cc: ipsec@ietf.org Subject: Re: [IPsec] is there any proposed solution to solve the anti-replay problem for IPsec pkts when subject to QOS classification 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, 25 Mar 2009 14:33:11 -0000 In your previous mail you wrote: In case we do QOS re-ordering (caused due to shaping & queueing) for traffic classes after encryption, the encrypted pkts get re-ordered thus changing the order of sequence numbers. At the receiving end, such out-of-order pkts are droped by IPsec since they do not fall under the anit-replay window range. Is there any proposed solution/draft which caters to this problem? If yes, it would be great if someone can point me to it. => this issue is well known in the IPsec community but: - after encryption there should be no reason to classify (then reorder) packets in different ways - before encryption you can setup with IKEv2 different SAs between the same end-points and then apply different QoS. In both cases the anti-replay window should not drop "old packets" from QoS reordering. Regards Francis.Dupont@fdupont.fr From kent@bbn.com Wed Mar 25 08:29:17 2009 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 816B128C10F for ; Wed, 25 Mar 2009 08:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.133, 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 5vkPNEvFD8+s for ; Wed, 25 Mar 2009 08:29:16 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 638CD28C1D9 for ; Wed, 25 Mar 2009 08:29:16 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.68.195]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LmV3Q-00038r-DL; Wed, 25 Mar 2009 11:30:08 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <673ac0640903250357w3dcdfb13y8ad2c3f7e38402e4@mail.gmail.com> References: <673ac0640903250357w3dcdfb13y8ad2c3f7e38402e4@mail.gmail.com> Date: Wed, 25 Mar 2009 11:30:03 -0400 To: Prabhat Hegde From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-974127487==_ma============" Cc: ipsec@ietf.org Subject: Re: [IPsec] is there any proposed solution to solve the anti-replay problem for IPsec pkts when subject to QOS classification 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, 25 Mar 2009 15:29:17 -0000 --============_-974127487==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 4:27 PM +0530 3/25/09, Prabhat Hegde wrote: >Hi, > In case we do QOS re-ordering (caused due to shaping & >queueing) for traffic classes after encryption, the encrypted pkts >get re-ordered thus changing the order of sequence numbers. At the >receiving end, such out-of-order pkts are droped by IPsec since they >do not fall under the anit-replay window range. > Is there any proposed solution/draft which caters to this >problem? If yes, it would be great if someone can point me to it. > >-- >With regards, >Prabhat > > I agree with Frances's reply; we made explicit provisions for this in 4301: If different classes of traffic (distinguished by Differentiated Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the same SA, and if the receiver is employing the optional anti-replay feature available in both AH and ESP, this could result in inappropriate discarding of lower priority packets due to the windowing mechanism used by this feature. Therefore, a sender SHOULD put traffic of different classes, but with the same selector values, on different SAs to support Quality of Service (QoS) appropriately. To permit this, the IPsec implementation MUST permit establishment and maintenance of multiple SAs between a given sender and receiver, with the same selectors. Distribution of traffic among these parallel SAs to support QoS is locally determined by the sender and is not negotiated by IKE. The receiver MUST process the packets from the different SAs without prejudice. These requirements apply to both transport and tunnel mode SAs. In the case of tunnel mode SAs, the DSCP values in question appear in the inner IP header. In transport mode, the DSCP value might change en route, but this should not cause problems with respect to IPsec processing since the value is not employed for SA selection and MUST NOT be checked as part of SA/packet validation. However, if significant re-ordering of packets occurs in an SA, e.g., as a result of changes to DSCP values en route, this may trigger packet discarding by a receiver due to application of the anti-replay mechanism. Steve --============_-974127487==_ma============ Content-Type: text/html; charset="us-ascii" Re: [IPsec] is there any proposed solution to solve the an
At 4:27 PM +0530 3/25/09, Prabhat Hegde wrote:
Hi,
      In case we do QOS re-ordering (caused due to shaping & queueing) for traffic classes after encryption, the encrypted pkts get re-ordered thus changing the order of sequence numbers. At the receiving end, such out-of-order pkts are droped by IPsec since they do not fall under the anit-replay window range.
        Is there any proposed solution/draft which caters to this problem? If yes, it would be great if someone can point me to it.

--
With regards,
Prabhat



I agree with Frances's reply; we made explicit provisions for this in 4301:

If different classes of traffic (distinguished by Differentiated
   Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on
   the same SA, and if the receiver is employing the optional
   anti-replay feature available in both AH and ESP, this could result
   in inappropriate discarding of lower priority packets due to the
   windowing mechanism used by this feature.  Therefore, a sender SHOULD
   put traffic of different classes, but with the same selector values,
   on different SAs to support Quality of Service (QoS) appropriately.
   To permit this, the IPsec implementation MUST permit establishment
   and maintenance of multiple SAs between a given sender and receiver,

   with the same selectors.  Distribution of traffic among these
   parallel SAs to support QoS is locally determined by the sender and
   is not negotiated by IKE.  The receiver MUST process the packets from
   the different SAs without prejudice.  These requirements apply to
   both transport and tunnel mode SAs.  In the case of tunnel mode SAs,
   the DSCP values in question appear in the inner IP header.  In
   transport mode, the DSCP value might change en route, but this should
   not cause problems with respect to IPsec processing since the value
   is not employed for SA selection and MUST NOT be checked as part of
   SA/packet validation.  However, if significant re-ordering of packets
   occurs in an SA, e.g., as a result of changes to DSCP values en
   route, this may trigger packet discarding by a receiver due to
   application of the anti-replay mechanism.

Steve
--============_-974127487==_ma============-- From yaronf@checkpoint.com Wed Mar 25 10:06:32 2009 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 2505D3A6BB3 for ; Wed, 25 Mar 2009 10:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[AWL=-0.121, 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 1B5hkEfm6-vw for ; Wed, 25 Mar 2009 10:06:31 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 8F4D93A69C9 for ; Wed, 25 Mar 2009 10:06:30 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 3F09B2CC003; Wed, 25 Mar 2009 19:07:22 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id E4BCB2CC001 for ; Wed, 25 Mar 2009 19:07:20 +0200 (IST) X-CheckPoint: {49CA62F4-0-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n2PH7KXw000723 for ; Wed, 25 Mar 2009 19:07:20 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 25 Mar 2009 19:07:19 +0200 From: Yaron Sheffer To: IPsecme WG Date: Wed, 25 Mar 2009 19:07:16 +0200 Thread-Topic: Slides uploaded Thread-Index: AcmtbCZcF2wwfLIZQumLvQHKHCi0zg== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D7CE97@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0230_01C9AD31.7A0795D0" MIME-Version: 1.0 Subject: [IPsec] Slides 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: Wed, 25 Mar 2009 17:06:32 -0000 ------=_NextPart_000_0230_01C9AD31.7A0795D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0231_01C9AD31.7A0795D0" ------=_NextPart_001_0231_01C9AD31.7A0795D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The Friday meeting's agenda, as well as (almost all) the slides are available at http://tools.ietf.org/wg/ipsecme/agenda. Thanks, Yaron ------=_NextPart_001_0231_01C9AD31.7A0795D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The Friday meeting’s agenda, as well as (almost = all) the slides are available at http://tools.ietf.org/wg= /ipsecme/agenda.

 

Thanks,

         =    Yaron

------=_NextPart_001_0231_01C9AD31.7A0795D0-- ------=_NextPart_000_0230_01C9AD31.7A0795D0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDMyNTE3MDcxNlowIwYJKoZIhvcNAQkEMRYEFCwjWb4omjiL spZgMZ7rm/Svx2ztMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA CQH96pyZ3O+voLJHyZlCIKKoRtl+Z+fC9RGNq3f08wEnm6Uk8KtGtxwRZhOcMXBiIW+IjH53StBA z/VAOeeLdBK9YBLyC/cKkuZR6SBwqj7e9VhZTjZL4VXo2xi+I/aYyJnTKchoXtc9Ny73Ymiwe+ww evL8zwesH4lxmg/1j7bXvoW4ojNcmw+PBpzO53LXUIfT8fN+NI5FbeHfzxWLq0u2hOihNTVsRbY9 USa8HUxqH4/rJOavBuP9FKROn7ftXNgkeWAVxU1Jl9jKXAtMr/czdgQ/hLVEXUfhbowP/uNnvAdn Ww1Y91gxeOr2Npt5T4E6Gt08eBQmfgJY5huFqAAAAAAAAA== ------=_NextPart_000_0230_01C9AD31.7A0795D0-- From wierbows@us.ibm.com Thu Mar 26 13:08:38 2009 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 5D5293A6A8E for ; Thu, 26 Mar 2009 13:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.657 X-Spam-Level: X-Spam-Status: No, score=-4.657 tagged_above=-999 required=5 tests=[AWL=1.341, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, 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 5sn1w0tZm0VC for ; Thu, 26 Mar 2009 13:08:37 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 630883A6A5B for ; Thu, 26 Mar 2009 13:08:37 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n2QK6RsR017356 for ; Thu, 26 Mar 2009 16:06:28 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2QK9UJ4184546 for ; Thu, 26 Mar 2009 16:09:30 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2QK9TAP024928 for ; Thu, 26 Mar 2009 16:09:30 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n2QK9Rw4024748 for ; Thu, 26 Mar 2009 16:09:27 -0400 To: ipsec@ietf.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David Wierbowski Date: Thu, 26 Mar 2009 16:09:25 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 03/26/2009 16:09:27 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFF16DFFE98308f9e8a93df938690918c0ABBFF16DFFE9830" Content-Disposition: inline Subject: [IPsec] Ticket #9 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, 26 Mar 2009 20:08:38 -0000 --0__=0ABBFF16DFFE98308f9e8a93df938690918c0ABBFF16DFFE9830 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Ticket #9 says"If the authentication fails in such ways that the entrie= s cannot create IKE SA (authentication failure or similar), then the resp= onse will be unencrypted, unauthenticated notify." Back in January there wa= s additional discussion about this issue. Several people supported sendi= ng the response as an encrypted, authenticated notify. The reason being t= hat the only entity who can send an encrypted, authenticated notify is the person with knowledge of SK_e* and SK_a*. Have we reach a decision yet? I thought we decided it was ok to send a= n encrypted, authenticated notify in this case and the initiator could ta= ke action on it because he knows it came from the person that he performed= the DH exchange with, but the ticket does not reflect that. Dave Wierbowski = --0__=0ABBFF16DFFE98308f9e8a93df938690918c0ABBFF16DFFE9830 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Ticket #9 says"If the authentication fails in such ways that th= e entries cannot create IKE SA (authentication failure or similar), the= n the response will be unencrypted, unauthenticated notify." Back= in January there was additional discussion about this issue. Several = people supported sending the response as an encrypted, authenticated no= tify. The reason being that the only entity who can send an encrypted,= authenticated notify is the person with knowledge of SK_e* and SK_a*.=

Have we reach a decision yet? I thought we decided it was ok to send a= n encrypted, authenticated notify in this case and the initiator could = take action on it because he knows it came from the person that he perf= ormed the DH exchange with, but the ticket does not reflect that.

Dave Wierbowski

= --0__=0ABBFF16DFFE98308f9e8a93df938690918c0ABBFF16DFFE9830-- From kivinen@iki.fi Thu Mar 26 18:42:24 2009 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 5E7EA3A6A37 for ; Thu, 26 Mar 2009 18:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, J_CHICKENPOX_42=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 OPCEizww1sHd for ; Thu, 26 Mar 2009 18:42:23 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 323273A6807 for ; Thu, 26 Mar 2009 18:42:22 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n2R1hDWa015924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Mar 2009 03:43:13 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n2R1hCrh006265; Fri, 27 Mar 2009 03:43:12 +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: <18892.12080.832734.93309@fireball.kivinen.iki.fi> Date: Fri, 27 Mar 2009 03:43:12 +0200 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 10 min Cc: ipsec@ietf.org Subject: [IPsec] Ticket #9 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, 27 Mar 2009 01:42:24 -0000 David Wierbowski writes: > Ticket #9 says"If the authentication fails in such ways that the entries > cannot create IKE SA (authentication failure or similar), then the response > will be unencrypted, unauthenticated notify." Back in January there was > additional discussion about this issue. Several people supported sending > the response as an encrypted, authenticated notify. The reason being that ^^^^^^^^^^^^^ > the only entity who can send an encrypted, authenticated notify is the > person with knowledge of SK_e* and SK_a*. That authenticated is very dangerous word there. The party sending that notification is NOT authenticated. He has not proven his identity by sending AUTH payload. As this error happens BEFORE he sends that payload, the notification will never be authenticated in the IKEv2 sense. It will be integrity protected, and they are known to be come from the same UNAUTHENTICATED party who responded to the IKE_SA_INIT exchange and did Diffie-Hellman. Man in the middle attacker can trivially fake that message, and if the receiving party actually takes them as authenticated error messages from the party he intended to talk to, he might do actions based on the attackers notifications. I agree there is benefit for allowing those encrypted and integrity protected notifications, as they do prove that they are sent by the same party who responded to the IKE_SA_INIT, thus they do tell that there is no point of continue that IKEv2 SA creation. On the other hand those cannot be taken as really authenticate errors, thus the initiator should still delete that partial IKEv2 SA attempt and try again (perhaps after suitable timeout). As it seems to be hard thing to distinguish for even here in the IPsec WG, I am afraid that it will be even harder for some implementor reading the draft to understand the difference between integrity protected and authenticated messages. This means that if those are allowed, they do require some text explaing this matter. > Have we reach a decision yet? I thought we decided it was ok to send an > encrypted, authenticated notify in this case and the initiator could take > action on it because he knows it came from the person that he performed the > DH exchange with, but the ticket does not reflect that. I am not sure we reached the decision yet, but I think more text is needed if that is allowed, thus creating that text might help moving things forward (i.e send replacement text). -- kivinen@iki.fi From pubs.hegde@gmail.com Fri Mar 27 09:30:30 2009 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 91EA53A6BB4 for ; Fri, 27 Mar 2009 09:30:30 -0700 (PDT) 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 rnaxaax5Vnjq for ; Fri, 27 Mar 2009 09:30:28 -0700 (PDT) Received: from mail-gx0-f160.google.com (mail-gx0-f160.google.com [209.85.217.160]) by core3.amsl.com (Postfix) with ESMTP id BA57328C1BC for ; Fri, 27 Mar 2009 09:30:27 -0700 (PDT) Received: by gxk4 with SMTP id 4so2325090gxk.13 for ; Fri, 27 Mar 2009 09:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=545efY4dNUsV+vmh6Y6N3HoLtj7VfE7xpubk1HziE70=; b=EdSCj6JLmQuToE9Dl38TRig+d13nronNVesfU8n/XB2HEuJuBF4KuuebmkxmSiR/cM +14Y4SAvftFLR9HMlbHm2/0oC6LXEAgw+oQ+oMjbqxvh/aJi7u5PkGnw2oApZZ5tjXXg eER2ge0fGxukoA89dZyYOhO2hpj5AqUFG+zNI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Onbiv6HJ7EhhRRnKOYXSwTix9dgGrMpFCpGBPjL67k/1oyWnhg2sCz1ti/PHb5NUkI 0axyw2SoTzCmx71sPFLJezm1tP6Kxp+z+ywa1V5pwxMxKODm9U9K4uhCYg/QRSyN4nYJ KmnDgJGGR6WDrKVpLsfuXCMy10kVzqEvqoUiU= MIME-Version: 1.0 Received: by 10.143.3.16 with SMTP id f16mr955277wfi.344.1238171481566; Fri, 27 Mar 2009 09:31:21 -0700 (PDT) In-Reply-To: <200903251434.n2PEY12N028413@givry.fdupont.fr> References: <673ac0640903250357w3dcdfb13y8ad2c3f7e38402e4@mail.gmail.com> <200903251434.n2PEY12N028413@givry.fdupont.fr> Date: Fri, 27 Mar 2009 22:01:21 +0530 Message-ID: <673ac0640903270931l5e06fca2q972e64f195f4a577@mail.gmail.com> From: Prabhat Hegde To: Francis Dupont Content-Type: multipart/alternative; boundary=001636e9106554708604661c4368 Cc: ipsec@ietf.org Subject: Re: [IPsec] is there any proposed solution to solve the anti-replay problem for IPsec pkts when subject to QOS classification 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, 27 Mar 2009 16:30:30 -0000 --001636e9106554708604661c4368 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Francis, - *after encryption there should be no reason to classify (then reorder) packets in different ways * -> There are two cases here: 1. QOS policies being applied on the logical tunnel interfaces Here, classification & marking take place before the crypto accelerator & the actual queueing & shaping of the resulting encrypted pkts happen on the physical interface facing the ISP. For queing & shaping to happen before the crypto engine we would have to change the driver code, equip the h/w accelerator with different set of queues, etc since the crypto engine serves mulitple interface each which can hold different QOS policies. 2. QOS policies being applied on the physical interface (or in addition to the one being applied in the logical interfaces) Here pkts destined to the physical interface matching an ipsec ruleset have to proceed to the crypto engine & then back to the physical interface after encryption. So in both of the above cases, the queueing & shaping happen on the physical interface which would cause re-ordering of encrypted pkts. - *before encryption you can setup with IKEv2 different SAs between the same end-points and then apply different QoS.* You mean IPSec SAs here. I am taking a look into this. But I must see how it affects the existing scalability. *In both cases the anti-replay window should not drop "old packets" from QoS reordering.* Work around would be to increase the size of the replay window, but I feel this is not a clean solution. On Wed, Mar 25, 2009 at 8:04 PM, Francis Dupont wrote: > In your previous mail you wrote: > > In case we do QOS re-ordering (caused due to shaping & queueing) > for > traffic classes after encryption, the encrypted pkts get re-ordered thus > changing the order of sequence numbers. At the receiving end, such > out-of-order pkts are droped by IPsec since they do not fall under the > anit-replay window range. > Is there any proposed solution/draft which caters to this > problem? > If yes, it would be great if someone can point me to it. > > => this issue is well known in the IPsec community but: > - after encryption there should be no reason to classify (then reorder) > packets in different ways > - before encryption you can setup with IKEv2 different SAs between the > same end-points and then apply different QoS. > In both cases the anti-replay window should not drop "old packets" from > QoS reordering. > > Regards > > Francis.Dupont@fdupont.fr > -- With regards, Prabhat --001636e9106554708604661c4368 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Francis,
=A0=A0=A0=A0=A0=A0 - after encryption there should be = no reason to classify (then reorder) packets in different ways
= =A0 -> There are two cases here:
1. QOS policies being applied on the= logical tunnel interfaces
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Here, classification & marking take place b= efore the crypto accelerator & the actual queueing & shaping of the= resulting encrypted pkts happen on the physical interface facing the ISP. = For queing & shaping to happen before the crypto engine we would have t= o change the driver code, equip the h/w accelerator with different set of q= ueues, etc since the crypto engine serves mulitple interface each which can= hold different QOS policies.
2. QOS policies being applied on the physical interface (or in addition to = the one being applied in the logical interfaces)
=A0=A0=A0=A0 Here pkts = destined to the physical interface matching an ipsec ruleset have to procee= d to the crypto engine & then back to the physical interface after encr= yption.
=A0=A0=A0=A0=A0 So in both of the above cases, the queueing & shaping h= appen on the physical interface which would cause re-ordering of encrypted = pkts.

=A0- before encryption you can setup with IKEv2 differen= t SAs between the same end-points and then apply different QoS.
You mean IPSec SAs here. I am taking a look into this. But I must see how i= t affects the existing scalability.

In both cases the anti-rep= lay window should not drop "old packets" from QoS reordering.=
=A0=A0 Work around would be to increase the size of the replay window, but = I feel this is not a clean solution.

On W= ed, Mar 25, 2009 at 8:04 PM, Francis Dupont <Francis.Dupont@fdupont.fr> wrote:
<= div class=3D"h5">=A0In your previous mail you wrote:

=A0 =A0 =A0 =A0 In case we do QOS re-ordering (caused due to shaping &= queueing) for
=A0 traffic classes after encryption, the encrypted pkts get re-ordered th= us
=A0 changing the order of sequence numbers. At the receiving end, such
=A0 out-of-order pkts are droped by IPsec since they do not fall under the=
=A0 anit-replay window range.
=A0 =A0 =A0 =A0 =A0 Is there any proposed solution/draft which caters to t= his problem?
=A0 If yes, it would be great if someone can point me to it.

=3D> this issue is well known in the IPsec community but: =A0- after encryption there should be no reason to classify (then reorder)<= br> =A0packets in different ways
=A0- before encryption you can setup with IKEv2 different SAs between the =A0same end-points and then apply different QoS.
In both cases the anti-replay window should not drop "old packets"= ; from
QoS reordering.

Regards

Francis.Dupont@fdupont.fr<= br>



--
With regards,Prabhat
--001636e9106554708604661c4368-- From Pasi.Eronen@nokia.com Fri Mar 27 10:24:41 2009 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 85BC63A679C for ; Fri, 27 Mar 2009 10:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 NsbrXGDjiCDj for ; Fri, 27 Mar 2009 10:24:40 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 680553A6A65 for ; Fri, 27 Mar 2009 10:24:40 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2RHPTjX016031; Fri, 27 Mar 2009 19:25:30 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 19:25:30 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 19:25:24 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Fri, 27 Mar 2009 18:25:24 +0100 From: To: , Date: Fri, 27 Mar 2009 18:25:29 +0100 Thread-Topic: [IPsec] Ticket #9 Thread-Index: AcmufW5uz8ixP2MGRh+m+V99VYDORwAgMkig Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F212107B@NOK-EUMSG-01.mgdnok.nokia.com> References: <18892.12080.832734.93309@fireball.kivinen.iki.fi> In-Reply-To: <18892.12080.832734.93309@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 X-OriginalArrivalTime: 27 Mar 2009 17:25:24.0778 (UTC) FILETIME=[03A590A0:01C9AF01] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Ticket #9 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, 27 Mar 2009 17:24:41 -0000 Tero Kivinen wrote: > I am not sure we reached the decision yet, but I think more text is > needed if that is allowed, thus creating that text might help moving > things forward (i.e send replacement text).=20 Here's a first sketch: Section 1.3.1: OLD:=20 Failure of an attempt to create a CHILD SA SHOULD NOT tear down the IKE SA: there is no reason to lose the work done to set up the IKE SA. When an IKE SA is not created, the error message return SHOULD NOT be encrypted because the other party will not be able to authenticate that message. [[ Note: this text may be changed in the future. ]] NEW: If creating the CHILD SA fails for any reason, the IKE SA stays up. (This section is about CREATE_CHILD_SA exchange, so the text about IKE_SA creation failures is in wrong place) Section 1.2: OLD: {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange fails for some reason, the IKE SA is still created as usual. The list of responses in the IKE_AUTH exchange that do not prevent an IKE SA from being set up include at least the following: NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. NEW: {{ Clarif-4.2 }} During the IKE_AUTH exchange, two kinds of=20 failures can happen.=20 If the failure is related to creating the Child SA, the IKE SA is still created as usual. The list of responses in the IKE_AUTH exchange that do not prevent an IKE SA from being set up include at least the following: NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. In this case, the error notification is included in the last IKE_AUTH response, and the SA/TSi/TSr payloads are omitted from this message. =20 If the failure is related to creating the IKE SA (for example, AUTHENTICATION_FAILED), the IKE_SA is not created. Note that although the IKE_AUTH messages are encrypted and integrity protected, if the peer receiving this notification has not authenticated the other end yet, the information needs to be treated with caution.=20 Best regards, Pasi= From Francis.Dupont@fdupont.fr Fri Mar 27 10:34:05 2009 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 4D21A3A6A56 for ; Fri, 27 Mar 2009 10:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 2BX2Hm8Yiaew for ; Fri, 27 Mar 2009 10:34:04 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 629C428C1D0 for ; Fri, 27 Mar 2009 10:32:46 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n2RHXdKn051477; Fri, 27 Mar 2009 18:33:39 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200903271733.n2RHXdKn051477@givry.fdupont.fr> From: Francis Dupont To: Prabhat Hegde In-reply-to: Your message of Fri, 27 Mar 2009 22:01:21 +0530. <673ac0640903270931l5e06fca2q972e64f195f4a577@mail.gmail.com> Date: Fri, 27 Mar 2009 18:33:39 +0100 Sender: Francis.Dupont@fdupont.fr Cc: ipsec@ietf.org Subject: Re: [IPsec] is there any proposed solution to solve the anti-replay problem for IPsec pkts when subject to QOS classification 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, 27 Mar 2009 17:34:05 -0000 In your previous mail you wrote: - *after encryption there should be no reason to classify (then reorder) packets in different ways * -> There are two cases here: 1. QOS policies being applied on the logical tunnel interfaces Here, classification & marking take place before the crypto => in my English "before" is the opposite of "after", i.e., you are clearly in the second case. accelerator & the actual queueing & shaping of the resulting encrypted pkts happen on the physical interface facing the ISP. For queing & shaping to happen before the crypto engine we would have to change the driver code, equip the h/w accelerator with different set of queues, etc since the crypto engine serves mulitple interface each which can hold different QOS policies. 2. QOS policies being applied on the physical interface (or in addition to the one being applied in the logical interfaces) Here pkts destined to the physical interface matching an ipsec ruleset have to proceed to the crypto engine & then back to the physical interface after encryption. So in both of the above cases, the queueing & shaping happen on the physical interface which would cause re-ordering of encrypted pkts. => queueing and shaping are done according to some kind of packet classification: there is nearly nothing usable to perform classification of encrypted packets. So what you say doesn't make sense for me. - *before encryption you can setup with IKEv2 different SAs between the same end-points and then apply different QoS.* You mean IPSec SAs here. I am taking a look into this. => yes, they are the IPsec SAs on which traffic will be sent. But I must see how it affects the existing scalability. *In both cases the anti-replay window should not drop "old packets" from QoS reordering.* Work around would be to increase the size of the replay window, but I feel this is not a clean solution. => please read the messages (*) you receive before arguing... The issue you believe you discovered was already addressed: IPsec works perfectly with (and without) QoS. The only concerns I ever saw about this was about the fact QoS handling is a covered channel (some communities are very paranoid about covered channels :-). Francis.Dupont@fdupont.fr PS: (*) mine and Steve Kent's. From kent@bbn.com Fri Mar 27 10:38:45 2009 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 0B95E3A6A4D for ; Fri, 27 Mar 2009 10:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 syp3cKlN2q1V for ; Fri, 27 Mar 2009 10:38:44 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 590C53A6968 for ; Fri, 27 Mar 2009 10:38:44 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.16.179]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LnG1q-0001Bq-DR; Fri, 27 Mar 2009 13:39:38 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <673ac0640903270931l5e06fca2q972e64f195f4a577@mail.gmail.com> References: <673ac0640903250357w3dcdfb13y8ad2c3f7e38402e4@mail.gmail.com> <200903251434.n2PEY12N028413@givry.fdupont.fr> <673ac0640903270931l5e06fca2q972e64f195f4a577@mail.gmail.com> Date: Fri, 27 Mar 2009 13:37:51 -0400 To: Prabhat Hegde From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ipsec@ietf.org, Francis Dupont Subject: Re: [IPsec] is there any proposed solution to solve the anti-replay problem for IPsec pkts when subject to QOS classification 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, 27 Mar 2009 17:38:45 -0000 Prabhat, With regard to your first observation, I'll note that your argument appears to be based on particular implementation choices. We don't generally consider changes to standards based on such choices, unless a lot of vendors indicate that there are no viable implementation options consistent with the standard. With regard to your second observation, the text I cited from 4301 clearly identified IPsec (not IKE) SAs as the way to accommodate QoS-induced reordering. The 64-packet receive window is a MINIMUM value. So a receiver is always free to make the window bigger. The impact of this is minimal for software implementations, but might be an issue in hardware, depending on how the window is implemented. Steve From paul.hoffman@vpnc.org Mon Mar 30 08:07:31 2009 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 8662428C117 for ; Mon, 30 Mar 2009 08:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=0.513, 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 G5KhZfSDCMF5 for ; Mon, 30 Mar 2009 08:07:30 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 6E82D28C113 for ; Mon, 30 Mar 2009 08:07:30 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2UF8Pew081306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Mar 2009 08:08:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 30 Mar 2009 08:08:24 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Minutes from Friday posted 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, 30 Mar 2009 15:07:31 -0000 ...at . Many thanks to Gabriel and Guy for taking the notes. Please comment on this thread if you think there is an error in the minutes, not if you disagree with something that was said at the meeting. If you want to comment on something that was said, please start a new email thread. Thanks! --Paul Hoffman, Director --VPN Consortium From vijay@wichorus.com Mon Mar 30 09:19:53 2009 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 C0F623A6A17 for ; Mon, 30 Mar 2009 09:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[AWL=1.034, 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 rQyYvdm2+Y5i for ; Mon, 30 Mar 2009 09:19:53 -0700 (PDT) Received: from QMTA13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by core3.amsl.com (Postfix) with ESMTP id E0F4C3A6930 for ; Mon, 30 Mar 2009 09:19:52 -0700 (PDT) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA13.emeryville.ca.mail.comcast.net with comcast id ZQmF1b0020vp7WLADULrBL; Mon, 30 Mar 2009 16:20:52 +0000 Received: from [192.168.1.193] ([67.161.28.136]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id ZULo1b0042wC77n8RULrEY; Mon, 30 Mar 2009 16:20:51 +0000 Message-ID: <49D0F160.7070207@wichorus.com> Date: Mon, 30 Mar 2009 09:20:48 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Kanagavel Rajan References: <8F798BFDA851B943B3A1B2510E9287850B52063C@airmail> In-Reply-To: <8F798BFDA851B943B3A1B2510E9287850B52063C@airmail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-redirect-06.txt - Notify Payload Length for REDIRECT message with NONCE 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, 30 Mar 2009 16:19:53 -0000 Hi, Kanagavel Rajan wrote: > Hello Vijay, > > In section 6.2, I noticed a nonce data is included in Redirect Notify > payload as part of IKE_SA_INIT response. > > But however, the payload length is set as either 13 or 25 and this does > not include the NONCE data length. > > Is this a missing case in the draft or is there is any other way to find > out the NONCE data length?? > > Can you please clarify on this point?? My bad. The payload length should include the nonce data length. Will fix it in the next revision. Vijay From kagarigi@cisco.com Tue Mar 31 05:01:51 2009 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 1349E3A6D37 for ; Tue, 31 Mar 2009 05:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8vKu-Llx8+E for ; Tue, 31 Mar 2009 05:01:50 -0700 (PDT) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 936B83A6855 for ; Tue, 31 Mar 2009 05:01:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,452,1233532800"; d="scan'208";a="46996829" Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-1.cisco.com with ESMTP; 31 Mar 2009 12:02:44 +0000 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2VC2jZ3020770; Tue, 31 Mar 2009 17:32:45 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2VC2iFP020177; Tue, 31 Mar 2009 12:02:44 GMT Received: from xmb-blr-415.apac.cisco.com ([64.104.140.144]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Mar 2009 17:32:44 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Mar 2009 17:32:43 +0530 Message-ID: <12CEFA6955F85042B5462C204F68519508EE3433@xmb-blr-415.apac.cisco.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F212107B@NOK-EUMSG-01.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Ticket #9 Thread-Index: AcmufW5uz8ixP2MGRh+m+V99VYDORwAgMkigAL6AMpA= References: <18892.12080.832734.93309@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F212107B@NOK-EUMSG-01.mgdnok.nokia.com> From: "Kalyani Garigipati (kagarigi)" To: , , X-OriginalArrivalTime: 31 Mar 2009 12:02:44.0062 (UTC) FILETIME=[9969BFE0:01C9B1F8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2921; t=1238500965; x=1239364965; c=relaxed/simple; s=inddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kagarigi@cisco.com; z=From:=20=22Kalyani=20Garigipati=20(kagarigi)=22=20 |Subject:=20RE=3A=20[IPsec]=20Ticket=20#9 |Sender:=20; bh=QFuOvBayva+Q7nLXnEuzurQDcTZugDy37rIUZbME38Y=; b=WsHktmfp5kS0Rtj8fhGiVB0XaxIbhtMWvgZGfN5hunZ2eLkCc0FQGJj9e7 bC8VBpENZIZARfn4Si/N2UAz13hnH+lz17Ng6IVXes3bi9ji+AdJAuLqxdXX fAkjIUpOUp; Authentication-Results: ind-dkim-1; header.From=kagarigi@cisco.com; dkim=pass ( sig from cisco.com/inddkim1002 verified; ); Cc: ipsec@ietf.org Subject: Re: [IPsec] Ticket #9 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, 31 Mar 2009 12:01:51 -0000 Hi , Please clarify the following . 1. Is it mandatory or optional (implementation dependent) to create an IKEV2 sa when IKE_AUTH exchange fails for reason like NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED ? Regards, Kalyani -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Friday, March 27, 2009 10:55 PM To: kivinen@iki.fi; wierbows@us.ibm.com Cc: ipsec@ietf.org Subject: Re: [IPsec] Ticket #9 Tero Kivinen wrote: > I am not sure we reached the decision yet, but I think more text is > needed if that is allowed, thus creating that text might help moving > things forward (i.e send replacement text).=20 Here's a first sketch: Section 1.3.1: OLD:=20 Failure of an attempt to create a CHILD SA SHOULD NOT tear down the IKE SA: there is no reason to lose the work done to set up the IKE SA. When an IKE SA is not created, the error message return SHOULD NOT be encrypted because the other party will not be able to authenticate that message. [[ Note: this text may be changed in the future. ]] NEW: If creating the CHILD SA fails for any reason, the IKE SA stays up. (This section is about CREATE_CHILD_SA exchange, so the text about IKE_SA creation failures is in wrong place) Section 1.2: OLD: {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange fails for some reason, the IKE SA is still created as usual. The list of responses in the IKE_AUTH exchange that do not prevent an IKE SA from being set up include at least the following: NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. NEW: {{ Clarif-4.2 }} During the IKE_AUTH exchange, two kinds of=20 failures can happen.=20 If the failure is related to creating the Child SA, the IKE SA is still created as usual. The list of responses in the IKE_AUTH exchange that do not prevent an IKE SA from being set up include at least the following: NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. In this case, the error notification is included in the last IKE_AUTH response, and the SA/TSi/TSr payloads are omitted from this message. =20 If the failure is related to creating the IKE SA (for example, AUTHENTICATION_FAILED), the IKE_SA is not created. Note that although the IKE_AUTH messages are encrypted and integrity protected, if the peer receiving this notification has not authenticated the other end yet, the information needs to be treated with caution.=20 Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From kagarigi@cisco.com Tue Mar 31 05:07:59 2009 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 6DB153A687C for ; Tue, 31 Mar 2009 05:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-ndvZxrK6k7 for ; Tue, 31 Mar 2009 05:07:58 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 80E903A680D for ; Tue, 31 Mar 2009 05:07:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,452,1233532800"; d="scan'208";a="277323397" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 31 Mar 2009 12:08:57 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2VC8vq0021185; Tue, 31 Mar 2009 05:08:57 -0700 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2VC8Y23002820; Tue, 31 Mar 2009 12:08:57 GMT Received: from xmb-blr-415.apac.cisco.com ([64.104.140.144]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Mar 2009 17:38:56 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Mar 2009 17:38:56 +0530 Message-ID: <12CEFA6955F85042B5462C204F68519508EE3437@xmb-blr-415.apac.cisco.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F212107B@NOK-EUMSG-01.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on TS_UNACCEPTABLE Thread-Index: AcmufW5uz8ixP2MGRh+m+V99VYDORwAgMkigAL6m8lA= References: <18892.12080.832734.93309@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F212107B@NOK-EUMSG-01.mgdnok.nokia.com> From: "Kalyani Garigipati (kagarigi)" To: , , X-OriginalArrivalTime: 31 Mar 2009 12:08:56.0355 (UTC) FILETIME=[77512730:01C9B1F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=628; t=1238501337; x=1239365337; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kagarigi@cisco.com; z=From:=20=22Kalyani=20Garigipati=20(kagarigi)=22=20 |Subject:=20Question=20on=20TS_UNACCEPTABLE |Sender:=20; bh=xPqLlMnoIPdeQTdyf3NmxcP1N2K14xM1l27aqPj6OFU=; b=mAUKD34eVNx7lvKhdkxFkPd5sPMgT5arCV0cGWjPKnWErF89JD8uzRTvem AtzKFrZZvmCszLqM6RVPPCCQFKqNT11T+diXFGKOH278ZxKM7v7CmSGmya93 Y54rIUcLqM; Authentication-Results: sj-dkim-4; header.From=kagarigi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: ipsec@ietf.org Subject: [IPsec] Question on TS_UNACCEPTABLE 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, 31 Mar 2009 12:07:59 -0000 Hi, Please clarify the following. On the responder , if creating the Child SA during the IKE_AUTH request processing fails for some reason like NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED, then should we be sending AUTH, IDr and CERT payloads as usual in AUTH response ? Something like below flow. HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, N[TS_UNACCEPTABLE]} Regards, Kalyani From paul.hoffman@vpnc.org Tue Mar 31 11:07:16 2009 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 DFCB128C141 for ; Tue, 31 Mar 2009 11:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.497, 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 uJQEIohKXbhw for ; Tue, 31 Mar 2009 11:07:16 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id DC4EB28C13E for ; Tue, 31 Mar 2009 11:07:15 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2VI8Bt4097258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Mar 2009 11:08:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <12CEFA6955F85042B5462C204F68519508EE3433@xmb-blr-415.apac.cisco.com> References: <188 92.12080.832734.93309@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F212107B@NOK-EUMSG-01.mgdnok.nokia.com> <12CEFA6955F85042B5462C204F68519508EE3433@xmb-blr-415.apac.cisco.com> Date: Tue, 31 Mar 2009 11:08:09 -0700 To: "Kalyani Garigipati (kagarigi)" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ipsec@ietf.org Subject: Re: [IPsec] Ticket #9 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, 31 Mar 2009 18:07:17 -0000 At 5:32 PM +0530 3/31/09, Kalyani Garigipati (kagarigi) wrote: >Hi , > >Please clarify the following . > >1. Is it mandatory or optional (implementation dependent) to create an >IKEV2 sa when IKE_AUTH exchange fails for reason like >NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, >SINGLE_PAIR_REQUIRED,INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED ? I am unclear on what you are asking. The IKE SA is already set up when the child SA creation fails. Thus, it does not need to be created. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Tue Mar 31 11:09:16 2009 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 88BF33A68D6 for ; Tue, 31 Mar 2009 11:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=0.489, 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 a-l1Bo34L9mT for ; Tue, 31 Mar 2009 11:09:15 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7FB673A6976 for ; Tue, 31 Mar 2009 11:09:15 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2VIABNt097400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Mar 2009 11:10:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <12CEFA6955F85042B5462C204F68519508EE3437@xmb-blr-415.apac.cisco.com> References: <188 92.12080.832734.93309@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F212107B@NOK-EUMSG-01.mgdnok.nokia.com> <12CEFA6955F85042B5462C204F68519508EE3437@xmb-blr-415.apac.cisco.com> Date: Tue, 31 Mar 2009 11:10:10 -0700 To: "Kalyani Garigipati (kagarigi)" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ipsec@ietf.org Subject: Re: [IPsec] Question on TS_UNACCEPTABLE 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, 31 Mar 2009 18:09:16 -0000 At 5:38 PM +0530 3/31/09, Kalyani Garigipati (kagarigi) wrote: >Hi, > >Please clarify the following. > >On the responder , if creating the Child SA during the IKE_AUTH request >processing fails for some reason like NO_PROPOSAL_CHOSEN, >TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,INTERNAL_ADDRESS_FAILURE, and >FAILED_CP_REQUIRED, then should we be sending AUTH, IDr and CERT >payloads as usual in AUTH response ? > >Something like below flow. > > >HDR, SK {IDi, [CERT,] [CERTREQ,] > [IDr,] AUTH, SAi2, > TSi, TSr} --> > > <-- HDR, SK {IDr, [CERT,] AUTH, > N[TS_UNACCEPTABLE]} Yes, you need to be sending IDr and AUTH. CERT is already optional, and I don't think anyone would be surprised if you didn't send it during the failure case. --Paul Hoffman, Director --VPN Consortium From yaronf@checkpoint.com Tue Mar 31 11:30:28 2009 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 D49AB28C148 for ; Tue, 31 Mar 2009 11:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_05=-1.11] 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 uihGdNhqJZTI for ; Tue, 31 Mar 2009 11:30:27 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 3D9EF3A6915 for ; Tue, 31 Mar 2009 11:30:27 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B22DF2CC003; Tue, 31 Mar 2009 21:31:25 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 601FD2CC001 for ; Tue, 31 Mar 2009 21:31:24 +0300 (IDT) X-CheckPoint: {49D25F39-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n2VIVNXw021005 for ; Tue, 31 Mar 2009 21:31:23 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 31 Mar 2009 21:31:23 +0300 From: Yaron Sheffer To: IPsecme WG Date: Tue, 31 Mar 2009 21:31:20 +0300 Thread-Topic: Working group documents: what's next Thread-Index: AcmyIhgFdZi5k8uPT/SiY4xhA21GIAAC9Oow Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE572@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE55C@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0017_01C9B248.07F29E60" MIME-Version: 1.0 Subject: [IPsec] Working group documents: what's next 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, 31 Mar 2009 18:30:28 -0000 ------=_NextPart_000_0017_01C9B248.07F29E60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Paul and I just posted a list of the group's documents and their status here: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/DocumentStatus If anything is missing or incorrect - in particular dates - please let us know. We have made a new year's promise to keep the list current :-) Honestly, we'll try to! The page is also linked from the main wiki page. Thanks, Yaron ------=_NextPart_000_0017_01C9B248.07F29E60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDMzMTE4MzExOVowIwYJKoZIhvcNAQkEMRYEFELmbOf8XfwJ XQ05k0Kcmvt2GrMeMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA QMjtEjEYJK96XIvC1EHwi/GzE+Miph0L1ODaLemEBeNBcj5kJtOvbuVTYyz6DGTs+S5QZC8LVVCT djTOjguBkea9dF4BDeahPbyQ/F52qHTBk8ahHFqhq4gVbWk+Pira0Q/PEUzy4cp/PHxZPoxVa+Mg 5k+DpdPvc/BOalYSaaZyyVqXeun87ZRGiU/JF6SwFu/R1OCaYa6OO5yh4FPjbUqkDP0nUwM2gLqM 0SZlfYByWPGR0NHco17EpTAkWxRXJpj7GjbLqW+LPJTe2bQPW8Q3Ue3fVU0h/xFKvDTqT74ut2wU dXGy2310i0MIQ1hnDWUqfj46K9vjcAC7X5vdFgAAAAAAAA== ------=_NextPart_000_0017_01C9B248.07F29E60-- From kagarigi@cisco.com Tue Mar 31 22:55:33 2009 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 461E93A6A26 for ; Tue, 31 Mar 2009 22:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4M8yDXtIYBA for ; Tue, 31 Mar 2009 22:55:32 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 388633A67AA for ; Tue, 31 Mar 2009 22:55:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,305,1235952000"; d="scan'208";a="149241526" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 01 Apr 2009 05:56:32 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n315uWRT023704; Tue, 31 Mar 2009 22:56:32 -0700 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n315uD5l003960; Wed, 1 Apr 2009 05:56:34 GMT Received: from xmb-blr-415.apac.cisco.com ([64.104.140.144]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 11:26:28 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Apr 2009 11:26:28 +0530 Message-ID: <12CEFA6955F85042B5462C204F68519508EE3641@xmb-blr-415.apac.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Ticket #9 Thread-Index: AcmyK7L5bHgBch5ZSFmO6RQSo08c6wAYoTVA References: <18892.12080.832734.93309@fireball.kivinen.iki.fi><808FD6E27AD4884E94820BC333B2DB7727F212107B@NOK-EUMSG-01.mgdnok.nokia.com><12CEFA6955F85042B5462C204F68519508EE3433@xmb-blr-415.apac.cisco.com> From: "Kalyani Garigipati (kagarigi)" To: "Paul Hoffman" X-OriginalArrivalTime: 01 Apr 2009 05:56:28.0153 (UTC) FILETIME=[9929E690:01C9B28E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1344; t=1238565392; x=1239429392; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kagarigi@cisco.com; z=From:=20=22Kalyani=20Garigipati=20(kagarigi)=22=20 |Subject:=20RE=3A=20[IPsec]=20Ticket=20#9 |Sender:=20; bh=EnGmM8PQCbt3bD369Bc/tjiUTVb8yCC6u1VXmQGqJko=; b=LCPGd83Vd6GtqtfmpxBe81FNv1ju3siqEmnpn1sJweuiQ2JhFqO3cpHH/F TmWfukeYQNg1wMi1zz/1BmIaUcEr62+Xqtm9PtH46tNfs09Di7Fld/iHJY2/ eBjAj4teaC; Authentication-Results: sj-dkim-2; header.From=kagarigi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: ipsec@ietf.org Subject: Re: [IPsec] Ticket #9 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, 01 Apr 2009 05:55:33 -0000 Hi Paul, My question was , during the AUTH exchange if failure happens due to reasons like NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED, Should we still bring IKEV2 SA as usual? RFC says we can still bring the IKeV2 SA as usual, but my doubt is if this is mandatory or optional? My question was not during Child SA Creation. Regards, kalyani -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Tuesday, March 31, 2009 11:38 PM To: Kalyani Garigipati (kagarigi) Cc: ipsec@ietf.org Subject: Re: [IPsec] Ticket #9 At 5:32 PM +0530 3/31/09, Kalyani Garigipati (kagarigi) wrote: >Hi , > >Please clarify the following . > >1. Is it mandatory or optional (implementation dependent) to create an >IKEV2 sa when IKE_AUTH exchange fails for reason like >NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, >SINGLE_PAIR_REQUIRED,INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED ? I am unclear on what you are asking. The IKE SA is already set up when the child SA creation fails. Thus, it does not need to be created. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Tue Mar 31 23:32:10 2009 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 AF8F43A6B96 for ; Tue, 31 Mar 2009 23:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.034, 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 itV7NoboIAd0 for ; Tue, 31 Mar 2009 23:32:09 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 6BC0D3A6B4D for ; Tue, 31 Mar 2009 23:32:07 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 709BE30C002; Wed, 1 Apr 2009 09:33:06 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 0D2CB2CC001; Wed, 1 Apr 2009 09:33:05 +0300 (IDT) X-CheckPoint: {49D30855-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n316X4Xw004868; Wed, 1 Apr 2009 09:33:04 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 1 Apr 2009 09:33:03 +0300 From: Yoav Nir To: "Kalyani Garigipati (kagarigi)" , Paul Hoffman Date: Wed, 1 Apr 2009 09:34:03 +0300 Thread-Topic: [IPsec] Ticket #9 Thread-Index: AcmyK7L5bHgBch5ZSFmO6RQSo08c6wAYoTVAAAE1ZLA= Message-ID: <9FB7C7CE79B84449B52622B506C780361332A1384E@il-ex01.ad.checkpoint.com> References: <18892.12080.832734.93309@fireball.kivinen.iki.fi><808FD6E27AD4884E94820BC333B2DB7727F212107B@NOK-EUMSG-01.mgdnok.nokia.com><12CEFA6955F85042B5462C204F68519508EE3433@xmb-blr-415.apac.cisco.com> <12CEFA6955F85042B5462C204F68519508EE3641@xmb-blr-415.apac.cisco.com> In-Reply-To: <12CEFA6955F85042B5462C204F68519508EE3641@xmb-blr-415.apac.cisco.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 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Ticket #9 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, 01 Apr 2009 06:32:10 -0000 Hi Kalyani. One way or the other, it has to be mandatory. The "dread" scenario is that = one peer thinks the IKE SA is set up, while the other thinks that it is not= . >From the discussion of Ticket #9, the consensus seems to be that with all t= hose child-SA specific reasons, the IKE SA is set up - it is not silently d= iscarded. Of course, IKE SAs are usually not set up as for their own sake, but as a m= eans to the end - the child SA. So if setting up the child SA fails, either= peer may decide that keeping the IKE SA is a waste of memory. In that case= either side can delete the IKE SA, but only by doing it explicitly with a = DELETE payload in an INFORMATIONAL exchange. Hope this helps Yoav=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Kalyani Garigipati (kagarigi) > Sent: Wednesday, April 01, 2009 8:56 AM > To: Paul Hoffman > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Ticket #9 >=20 > Hi Paul, >=20 > My question was , during the AUTH exchange if failure happens=20 > due to reasons like NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE,=20 > SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and=20 > FAILED_CP_REQUIRED, Should we still bring IKEV2 SA as usual?=20 > RFC says we can still bring the > IKeV2 SA as usual, but my doubt is if this is mandatory or optional? >=20 > My question was not during Child SA Creation. >=20 > Regards, > kalyani >=20 >=20 >=20 >=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Paul Hoffman > Sent: Tuesday, March 31, 2009 11:38 PM > To: Kalyani Garigipati (kagarigi) > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Ticket #9 >=20 > At 5:32 PM +0530 3/31/09, Kalyani Garigipati (kagarigi) wrote: > >Hi , > > > >Please clarify the following . > > > >1. Is it mandatory or optional (implementation dependent) to=20 > create an > >IKEV2 sa when IKE_AUTH exchange fails for reason like=20 > >NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE,=20 > >SINGLE_PAIR_REQUIRED,INTERNAL_ADDRESS_FAILURE, and=20 > FAILED_CP_REQUIRED ? >=20 > I am unclear on what you are asking. The IKE SA is already=20 > set up when the child SA creation fails. Thus, it does not=20 > need to be created. >=20 > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > 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 >=20 > Scanned by Check Point Total Security Gateway. > = Email secured by Check Point