From nobody Fri May 2 05:27:56 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1911A6F74 for ; Fri, 2 May 2014 05:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4HKhNX9lUmz for ; Fri, 2 May 2014 05:27:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ED35C1A6F44 for ; Fri, 2 May 2014 05:27:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDT35995; Fri, 02 May 2014 12:27:49 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 2 May 2014 13:26:24 +0100 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 2 May 2014 13:27:46 +0100 Received: from szxeml561-mbx.china.huawei.com ([169.254.5.235]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.03.0158.001; Fri, 2 May 2014 20:27:43 +0800 From: Syed Ajim Hussain To: "ipsec@ietf.org" Thread-Topic: Simultaneous Child SA Creation tigger from both the side. Thread-Index: AQHPZgHpY6RXSVirykaaimoh8LSrQQ== Date: Fri, 2 May 2014 12:27:41 +0000 Message-ID: <335B84BDA2818C428E63D9B0ADE6863545AF7228@szxeml561-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.144.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ShckbnDkKcjCjXth91gLuhRtzkY Subject: [IPsec] Simultaneous Child SA Creation tigger from both the side. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 12:27:55 -0000 Hi All.=20 Host A --------------Host B =20 Assume Host-A & Host-B want to established IPSEC Tunnel, First they es= tablished one IKE SA and one IPSEC SA (Child SA). =20 After that due to addition of a new IPSEC Policy(SPD), Both the sides = triggered one more Child SA creation.=20 This Child SA creation hit simultaneous Child SA Creation condition. Si= nce both the side triggered for Child SA =20 Creation for one Configured SPD (Traffic Flow).=20 In RFC 5996 , there is no point mention about simultaneous exchange dur= ing Child SA create, it only mention Simultaneous=20 Handling during Child SA Rekey. =20 What should be the behavior in case of Simultaneous Child SA Creation,= if implementation maintain one Child SA per one Traffic Flow (SPD). =20 Does Simultaneous Child SA Rekeying - method also applicable in case o= f Child SA Creation (not Rekey). =20 =20 2.8.1. Simultaneous Child SA Rekeying If the two ends have the same lifetime policies, it is possible that both will initiate a rekeying at the same time (which will result in redundant SAs). To reduce the probability of this happening, the timing of rekeying requests SHOULD be jittered (delayed by a random amount of time after the need for rekeying is noticed). Kaufman, et al. Standards Track [Page 36] =20 RFC 5996 IKEv2bis September 2010 This form of rekeying may temporarily result in multiple similar SAs between the same pairs of nodes. When there are two SAs eligible to receive packets, a node MUST accept incoming packets through either SA. If redundant SAs are created though such a collision, the SA created with the lowest of the four nonces used in the two exchanges SHOULD be closed by the endpoint that created it. "Lowest" means an octet-by-octet comparison (instead of, for instance, comparing the nonces as large integers). In other words, start by comparing the first octet; if they're equal, move to the next octet, and so on. If you reach the end of one nonce, that nonce is the lower one. The node that initiated the surviving rekeyed SA should delete the replaced SA after the new one is established. The following is an explanation on the impact this has on implementations. Assume that hosts A and B have an existing Child SA pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same time: Host A Host B ------------------------------------------------------------------- send req1: N(REKEY_SA,SPIa1), SA(..,SPIa2,..),Ni1,.. --> <-- send req2: N(REKEY_SA,SPIb1), SA(..,SPIb2,..),Ni2 recv req2 <-- At this point, A knows there is a simultaneous rekeying happening. However, it cannot yet know which of the exchanges will have the lowest nonce, so it will just note the situation and respond as usual. send resp2: SA(..,SPIa3,..), Nr1,.. --> --> recv req1 Now B also knows that simultaneous rekeying is going on. It responds as usual. <-- send resp1: SA(..,SPIb3,..), Nr2,.. recv resp1 <-- --> recv resp2 At this point, there are three Child SA pairs between A and B (the old one and two new ones). A and B can now compare the nonces. Suppose that the lowest nonce was Nr1 in message resp2; in this case, B (the sender of req2) deletes the redundant new SA, and A (the node that initiated the surviving rekeyed SA), deletes the old one. Kaufman, et al. Standards Track [Page 37] =20 RFC 5996 IKEv2bis September 2010 send req3: D(SPIa1) --> <-- send req4: D(SPIb2) --> recv req3 <-- send resp3: D(SPIb1) recv req4 <-- send resp4: D(SPIa3) --> The rekeying is now finished. However, there is a second possible sequence of events that can happen if some packets are lost in the network, resulting in retransmissions. The rekeying begins as usual, but A's first packet (req1) is lost. Host A Host B ------------------------------------------------------------------- send req1: N(REKEY_SA,SPIa1), SA(..,SPIa2,..), Ni1,.. --> (lost) <-- send req2: N(REKEY_SA,SPIb1), SA(..,SPIb2,..),Ni2 recv req2 <-- send resp2: SA(..,SPIa3,..), Nr1,.. --> --> recv resp2 <-- send req3: D(SPIb1) recv req3 <-- send resp3: D(SPIa1) --> --> recv resp3 From B's point of view, the rekeying is now completed, and since it has not yet received A's req1, it does not even know that there was simultaneous rekeying. However, A will continue retransmitting the message, and eventually it will reach B. resend req1 --> --> recv req1 To B, it looks like A is trying to rekey an SA that no longer exists; thus, B responds to the request with something non-fatal such as CHILD_SA_NOT_FOUND. <-- send resp1: N(CHILD_SA_NOT_FOUND) recv resp1 <-- When A receives this error, it already knows there was simultaneous rekeying, so it can ignore the error message From nobody Fri May 2 07:14:50 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A1A1A2119 for ; Fri, 2 May 2014 07:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ghv2IsbDpYjn for ; Fri, 2 May 2014 07:14:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B583E1A6FB4 for ; Fri, 2 May 2014 07:14:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGI45365; Fri, 02 May 2014 14:14:42 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 2 May 2014 15:13:36 +0100 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 2 May 2014 15:14:40 +0100 Received: from SZXEML513-MBX.china.huawei.com ([169.254.7.157]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.03.0158.001; Fri, 2 May 2014 22:14:31 +0800 From: vijay kn To: "vijay@wichorus.com" , "kilian.weniger@googlemail.com" , "ipsec@ietf.org" Thread-Topic: Regarding IKEv2 REDIRECT problem (reference RFC 5685) Thread-Index: Ac9mCR4Wj8NaQqRJSGu1iyUmq2WiKQAB4oDw Date: Fri, 2 May 2014 14:14:30 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.146.58] Content-Type: multipart/alternative; boundary="_000_AD5AD8B0B070044BAD3C37D7057F37E153FE638Dszxeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/vzeYysU2lutaa1QL7FQubsRWUF8 Cc: vijay kn , "vjkumar2003@gmail.com" Subject: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 14:14:48 -0000 --_000_AD5AD8B0B070044BAD3C37D7057F37E153FE638Dszxeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There is an issue in IKEv2 REDIRECT RFC 5685. In one scenario, the IKEv2 RE= DIRECT will not work indefinitely. Scenario: - Let's assume there are about 1000 clients connected to a IKEv2 REDIRECT ena= bled SeGW. None of the clients were IKEv2 redirect enabled at the time of e= stablishing SA with the SeGW (meaning they have not sent the REDIRECT_SUPPO= RTED notification in the IKE_SA_INIT message) This will lead to a situation where the SeGW is loaded and wanting to redir= ect some clients to another SeGW but it cannot REDIRECT them as none of the= m have indicated REDIRECT support in the IKE_SA_INIT message. If the user/operator enabled REDIRECT functionality dynamically (like after= SAs were established), then the SeGW is not going to redirect them because= it had not received a REDIRECT_SUPPORTED payload from the clients. Effect/Impact: - This leads to a congestion/overload at the gateway when the base stations c= onnecting to the SeGW are several hundred/thousands in number. In the LTE a= nd LTE-A scenarios, this condition is possible where the number of base sta= tions connecting to the SeGW are very high. Suggestion/Solution: - A change is required in RFC 5685 is required as below: - ""Whenever the redirect feature/functionality is enabled at run-time, the c= lient should indicate the same to the SeGW. This can be done by the client = sending an INFORMATIONAL message under the protection of the IKE SA. This = message MUST have a REDIRECT_SUPPORTED notify payload to enable the SeGW to= redirect them at run-time even though they had initially connected with Se= GW without REDIRECT support"" Request for comments: - Please read the problem, impact and solution listed above and let me know i= f any comments. Hope my point is valid and needs to be incorporated as the = RFC update. Regards, Vijay N. --_000_AD5AD8B0B070044BAD3C37D7057F37E153FE638Dszxeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

There is an issue in I= KEv2 REDIRECT RFC 5685. In one scenario, the IKEv2 REDIRECT will not= work indefinitely.

 

Scenario: -

Let’s assume there are about 1000 clients conn= ected to a IKEv2 REDIRECT enabled SeGW. None of the clients were IKEv2 redirect enabled at the time of establish= ing SA with the SeGW (meaning they have not sent the REDIRECT_SUPPORTED= notification in the

IKE_SA_INIT message)

This will lead to a situation where the SeGW is load= ed and wanting to redirect some clients to another SeGW but it cannot REDIR= ECT them as none of them have indicated REDIRECT support in the IKE_SA_INIT= message.

If the user/operator enabled REDIRECT functionality = dynamically (like after SAs were established), then the SeGW is not going t= o redirect them because it had not received a REDIRECT_SUPPORTED payload fr= om the clients.

 

Effect/Impact: -

This leads to a congestion/overload at the gateway w= hen the base stations connecting to the SeGW are several hundred/thousands = in number. In the LTE and LTE-A scenarios, this condition is possible where= the number of base stations connecting to the SeGW are very high.

 

Suggestion/Solution: -

A change is required in RFC 5685 is required as belo= w: -

“”Whenever= the redirect feature/functionality is enabled at run-time, the client shou= ld indicate the same to the SeGW. This can be done by the client sending an= INFORMATIONAL message  under the protection of the IKE SA. This message MUST have a REDIRECT_SUPPORTED notify payload to = enable the SeGW to redirect them at run-time even though they had initially= connected with SeGW without REDIRECT support””

 

Request for comments: -

Please read the problem, impact and solution listed = above and let me know if any comments. Hope my point is valid and needs to = be incorporated as the RFC update.

 

 

Regards,

Vijay N.

 

--_000_AD5AD8B0B070044BAD3C37D7057F37E153FE638Dszxeml513mbxchi_-- From nobody Sun May 4 00:18:56 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7496B1A015F for ; Sun, 4 May 2014 00:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFvImL8W5S58 for ; Sun, 4 May 2014 00:18:52 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACC31A00F9 for ; Sun, 4 May 2014 00:18:51 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id l18so5214951wgh.11 for ; Sun, 04 May 2014 00:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=g5baj2hi5S9J5vbFw/mAOgKEKcVAzTtzpzmUwHWPWQo=; b=xyP7vCRawzGIai9q3Pq3ctfuQpZ31vzQDeN0nukNtsBVvZY0MiF8nBVhs3fxg99oOa oQuwolgBsnFSUlXbBivXP4Izvu7ecBGv0jDbFpfuBbRjFiFxN0AqOY180G/uv6a6z8GF 9MGrhapnZ3BtHbVWhGE0NEAzuEaWw4EZ89KrRZsWe95U+B9aeDDZODJBUTucIbaup2pF 3939sCdKbZpA176iODiaScz8W/S34bH1EiUrHg6HpA8DGFOHhkL+z25H+p+D6vfPAWdV gWLFVAX6/AibJmbjq9pz/nMpCtUBmBCYr7oxqWLLZ1J1b4MZPeiIHbpN3cvLXPv61Y6E hqOA== X-Received: by 10.180.82.7 with SMTP id e7mr10578766wiy.6.1399187928650; Sun, 04 May 2014 00:18:48 -0700 (PDT) Received: from [172.24.249.242] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id h19sm9015308wiw.17.2014.05.04.00.18.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 04 May 2014 00:18:48 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: <335B84BDA2818C428E63D9B0ADE6863545AF7228@szxeml561-mbx.china.huawei.com> Date: Sun, 4 May 2014 10:18:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <335B84BDA2818C428E63D9B0ADE6863545AF7228@szxeml561-mbx.china.huawei.com> To: Syed Ajim Hussain X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/32on78gEQR_gvkKQFl8TrIm632E Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Simultaneous Child SA Creation tigger from both the side. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 07:18:54 -0000 Hi The reason that we don=92t have any mention of simultaneous SA creation = is that this issue has not come up in practice. When two IPsec hosts = don=92t have an SA for a particular flow (because said flow hasn=92t had = traffic in a while), it=92s highly unlikely that bidirectional traffic = on this flow will begin simultaneously, or at least before the 1-2 = roundtrips it takes to set up a child SA. On the other hand, when SA lifetimes are set and traffic is continuous, = it=92s very likely that two such implementations will begin a rekeying = at the same time. So what would happen? Both implementations get a CreateChildSA request = (or an IKE_AUTH request) after each has sent out its own request. I = guess we could specify it the same way as in section 2.8.1, but doing = this would be a problem because this is not specified and other = implementations are likely not to do it. Sorry I don=92t have a better answer for you. Yoav On May 2, 2014, at 3:27 PM, Syed Ajim Hussain wrote: > Hi All.=20 >=20 > Host A --------------Host B =20 >=20 > Assume Host-A & Host-B want to established IPSEC Tunnel, First = they established one IKE SA and one IPSEC SA (Child SA). =20 >=20 > After that due to addition of a new IPSEC Policy(SPD), Both the = sides triggered one more Child SA creation.=20 >=20 > This Child SA creation hit simultaneous Child SA Creation = condition. Since both the side triggered for Child SA =20 > Creation for one Configured SPD (Traffic Flow).=20 >=20 > In RFC 5996 , there is no point mention about simultaneous exchange = during Child SA create, it only mention Simultaneous=20 > Handling during Child SA Rekey. =20 >=20 > What should be the behavior in case of Simultaneous Child SA = Creation, if implementation maintain one Child SA per one Traffic Flow = (SPD). =20 >=20 > Does Simultaneous Child SA Rekeying - method also applicable in = case of Child SA Creation (not Rekey). =20 >=20 >=20 > 2.8.1. Simultaneous Child SA Rekeying >=20 > If the two ends have the same lifetime policies, it is possible that > both will initiate a rekeying at the same time (which will result in > redundant SAs). To reduce the probability of this happening, the > timing of rekeying requests SHOULD be jittered (delayed by a random > amount of time after the need for rekeying is noticed). >=20 >=20 >=20 >=20 > Kaufman, et al. Standards Track [Page = 36] >=20 > RFC 5996 IKEv2bis September = 2010 >=20 >=20 > This form of rekeying may temporarily result in multiple similar SAs > between the same pairs of nodes. When there are two SAs eligible to > receive packets, a node MUST accept incoming packets through either > SA. If redundant SAs are created though such a collision, the SA > created with the lowest of the four nonces used in the two exchanges > SHOULD be closed by the endpoint that created it. "Lowest" means an > octet-by-octet comparison (instead of, for instance, comparing the > nonces as large integers). In other words, start by comparing the > first octet; if they're equal, move to the next octet, and so on. = If > you reach the end of one nonce, that nonce is the lower one. The > node that initiated the surviving rekeyed SA should delete the > replaced SA after the new one is established. >=20 > The following is an explanation on the impact this has on > implementations. Assume that hosts A and B have an existing Child = SA > pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same > time: >=20 > Host A Host B > ------------------------------------------------------------------- > send req1: N(REKEY_SA,SPIa1), > SA(..,SPIa2,..),Ni1,.. --> > <-- send req2: N(REKEY_SA,SPIb1), > SA(..,SPIb2,..),Ni2 > recv req2 <-- >=20 > At this point, A knows there is a simultaneous rekeying happening. > However, it cannot yet know which of the exchanges will have the > lowest nonce, so it will just note the situation and respond as > usual. >=20 > send resp2: SA(..,SPIa3,..), > Nr1,.. --> > --> recv req1 >=20 > Now B also knows that simultaneous rekeying is going on. It = responds > as usual. >=20 > <-- send resp1: SA(..,SPIb3,..), > Nr2,.. > recv resp1 <-- > --> recv resp2 >=20 > At this point, there are three Child SA pairs between A and B (the > old one and two new ones). A and B can now compare the nonces. > Suppose that the lowest nonce was Nr1 in message resp2; in this = case, > B (the sender of req2) deletes the redundant new SA, and A (the node > that initiated the surviving rekeyed SA), deletes the old one. >=20 >=20 >=20 > Kaufman, et al. Standards Track [Page = 37] >=20 > RFC 5996 IKEv2bis September = 2010 >=20 >=20 > send req3: D(SPIa1) --> > <-- send req4: D(SPIb2) > --> recv req3 > <-- send resp3: D(SPIb1) > recv req4 <-- > send resp4: D(SPIa3) --> >=20 > The rekeying is now finished. >=20 > However, there is a second possible sequence of events that can > happen if some packets are lost in the network, resulting in > retransmissions. The rekeying begins as usual, but A's first packet > (req1) is lost. >=20 > Host A Host B > ------------------------------------------------------------------- > send req1: N(REKEY_SA,SPIa1), > SA(..,SPIa2,..), > Ni1,.. --> (lost) > <-- send req2: N(REKEY_SA,SPIb1), > SA(..,SPIb2,..),Ni2 > recv req2 <-- > send resp2: SA(..,SPIa3,..), > Nr1,.. --> > --> recv resp2 > <-- send req3: D(SPIb1) > recv req3 <-- > send resp3: D(SPIa1) --> > --> recv resp3 >=20 > =46rom B's point of view, the rekeying is now completed, and since = it > has not yet received A's req1, it does not even know that there was > simultaneous rekeying. However, A will continue retransmitting the > message, and eventually it will reach B. >=20 > resend req1 --> > --> recv req1 >=20 > To B, it looks like A is trying to rekey an SA that no longer = exists; > thus, B responds to the request with something non-fatal such as > CHILD_SA_NOT_FOUND. >=20 > <-- send resp1: N(CHILD_SA_NOT_FOUND) > recv resp1 <-- >=20 > When A receives this error, it already knows there was simultaneous > rekeying, so it can ignore the error message >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sun May 4 00:26:26 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4B91A0175 for ; Sun, 4 May 2014 00:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhmA6U6YR0cu for ; Sun, 4 May 2014 00:26:21 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 29FE71A0160 for ; Sun, 4 May 2014 00:26:20 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n15so1415279wiw.14 for ; Sun, 04 May 2014 00:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=KI9M6ugIPaUvw8IrdpzSFnem6nGST1OKyZzruNj9ptc=; b=NuNaYXeQz1pzPxc0i8k3+pzRP9IaQHwWFJt5S7My6lJUkzfa/j/pLZ1tLpYpFlwOpA OHJsVjDe4CmNffBghLySbSsaKX4HvvRnz50MWXCo56Ka9wcYVxB3n13DAWFpCTYCN8uM UV3lTPcqyYtt/kmWes9Nv5XZAgRaPpwEEmMVI34JmTChiMXtcQeo+AQa+EPScD65dbGv WhbHRTzYP0RhEc4bEUZdOtHOUJoZSLg4QNDn/EjlvgEv5XAR/KhVhDLLZAkDh1k4bdFa fwTHkbnFZ96QR469KgU1eHQi8u5l9cP2SVWCFJMaXktvUvptVgLCHuMixE31HCNxn9jC cK+w== X-Received: by 10.194.19.161 with SMTP id g1mr21797764wje.20.1399188377584; Sun, 04 May 2014 00:26:17 -0700 (PDT) Received: from [172.24.249.242] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id pm5sm10630940wjc.11.2014.05.04.00.26.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 04 May 2014 00:26:17 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CCFEB933-378A-4913-ABD9-66CCC4BBAD6D" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: Date: Sun, 4 May 2014 10:26:15 +0300 Message-Id: <22DBA0CE-BF37-48E2-A87D-B1D66E64DE1B@gmail.com> References: To: vijay kn X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/oAnKMJBeNmQG_FLp7YAjage0kss Cc: "ipsec@ietf.org" , "vijay@wichorus.com" , "kilian.weniger@googlemail.com" , "vjkumar2003@gmail.com" Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 07:26:24 -0000 --Apple-Mail=_CCFEB933-378A-4913-ABD9-66CCC4BBAD6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Vijay I=92m no expert on REDIRECT, and my implementation does not support it.=20= Your issue seems to be about implementations that have the REDIRECT = functionality, but don=92t advertise as much when they connect to the = peer gateway. So it=92s as if this feature is disabled by configuration. = Am I understanding this correctly? =20 So my question to you would be why this would make sense. Why do these = clients enable and disable the feature during the lifetime on an IKEv2 = SA? Why not leave is always on? Is this some kind of roaming issue? Yoav On May 2, 2014, at 5:14 PM, vijay kn wrote: > Hi, > There is an issue in IKEv2 REDIRECT RFC 5685. In one scenario, the = IKEv2 REDIRECT will not work indefinitely. > =20 > Scenario: - > Let=92s assume there are about 1000 clients connected to a IKEv2 = REDIRECT enabled SeGW. None of the clients were IKEv2 redirect enabled = at the time of establishing SA with the SeGW (meaning they have not sent = the REDIRECT_SUPPORTED notification in the > IKE_SA_INIT message) > This will lead to a situation where the SeGW is loaded and wanting to = redirect some clients to another SeGW but it cannot REDIRECT them as = none of them have indicated REDIRECT support in the IKE_SA_INIT message. > If the user/operator enabled REDIRECT functionality dynamically (like = after SAs were established), then the SeGW is not going to redirect them = because it had not received a REDIRECT_SUPPORTED payload from the = clients. > =20 > Effect/Impact: - > This leads to a congestion/overload at the gateway when the base = stations connecting to the SeGW are several hundred/thousands in number. = In the LTE and LTE-A scenarios, this condition is possible where the = number of base stations connecting to the SeGW are very high. > =20 > Suggestion/Solution: - > A change is required in RFC 5685 is required as below: - > =93=94Whenever the redirect feature/functionality is enabled at = run-time, the client should indicate the same to the SeGW. This can be = done by the client sending an INFORMATIONAL message under the = protection of the IKE SA. This message MUST have a REDIRECT_SUPPORTED = notify payload to enable the SeGW to redirect them at run-time even = though they had initially connected with SeGW without REDIRECT support=94=94= > =20 > Request for comments: - > Please read the problem, impact and solution listed above and let me = know if any comments. Hope my point is valid and needs to be = incorporated as the RFC update. > =20 > =20 > Regards, > Vijay N. > =20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_CCFEB933-378A-4913-ABD9-66CCC4BBAD6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Vijay

I=92m no expert on REDIRECT, and my = implementation does not support it. 

Your = issue seems to be about implementations that have the REDIRECT = functionality, but don=92t advertise as much when they connect to the = peer gateway. So it=92s as if this feature is disabled by configuration. = Am I understanding this correctly?  

So my = question to you would be why this would make sense. Why do these clients = enable and disable the feature during the lifetime on an IKEv2 SA? Why = not leave is always on?

Is this some kind of = roaming issue?

Yoav

On = May 2, 2014, at 5:14 PM, vijay kn <vijay.kn@huawei.com> = wrote:

Hi,
There is an issue = in IKEv2 REDIRECT RFC 5685. In one scenario, the = IKEv2 REDIRECT will not work indefinitely.
 
Scenario: -
Let=92s assume there are about 1000 clients connected to a = IKEv2 REDIRECT enabled SeGW. None of the clients were = IKEv2 redirect enabled at the time of establishing SA with the SeGW (meaning they = have not sent the REDIRECT_SUPPORTED notification in = the
IKE_SA_INIT = message)
This will lead to a = situation where the SeGW is loaded and wanting to redirect some clients = to another SeGW but it cannot REDIRECT them as none of them have = indicated REDIRECT support in the IKE_SA_INIT = message.
If the user/operator = enabled REDIRECT functionality dynamically (like after SAs were = established), then the SeGW is not going to redirect them because it had = not received a REDIRECT_SUPPORTED payload from the = clients.
 
Effect/Impact: -
This leads to a congestion/overload at the gateway when the = base stations connecting to the SeGW are several hundred/thousands in = number. In the LTE and LTE-A scenarios, this condition is possible where = the number of base stations connecting to the SeGW are very = high.
 
Suggestion/Solution: -
A change is required in RFC 5685 is required as = below: -
=93=94Whenever the redirect feature/functionality is = enabled at run-time, the client should indicate the same to the SeGW. = This can be done by the client sending an INFORMATIONAL message =  under the protection of the IKE SA. This message MUST have a = REDIRECT_SUPPORTED notify payload to enable the SeGW to redirect them at = run-time even though they had initially connected with SeGW without = REDIRECT support=94=94
 
Request = for comments: -
Please = read the problem, impact and solution listed above and let me know if = any comments. Hope my point is valid and needs to be incorporated as the = RFC update.
 
 
Regards,
Vijay = N.
 
________________________________= _______________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_CCFEB933-378A-4913-ABD9-66CCC4BBAD6D-- From nobody Sun May 4 09:11:03 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E365B1A00DE for ; Sun, 4 May 2014 09:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0xanVJZhK8g for ; Sun, 4 May 2014 09:10:53 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 696FC1A00D5 for ; Sun, 4 May 2014 09:10:53 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id uy17so3780925igb.5 for ; Sun, 04 May 2014 09:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mywzgXLfHMFq11QHXAfphcPSb/aSblgTQiuf9h0xiVs=; b=hI7RV6wEHwmZDCxHUGbdWz1QCH3GBXj04IWfaWwHOcOvggUO40aGtVQcSwk/rfBIj8 XLDbVFinYcLNC96xeF+dgpuqyPRDrtOckv/RxUDzOdelqX0X3wxrXiLsq3yuMv4NsWzV p8u2xY1Vuf23GlhUourw5EpDGWxahUeqmcdtqYhEDnUwjkJ8wyG7ONWT9s8XNRyR25Ug OsR1RtFtmsme1r/nl+ksFzllPpYBxqMr+o0RYffJudPo8rj0N39ahOtJVnLP6hbnnR0M Ke+KEV13zSzfG76iwxZznL3RXOTewkn6ajLG5zUSd0nKQF+w6a8Y2W90xhV9jMXveQHb jITg== X-Received: by 10.42.40.83 with SMTP id k19mr27784953ice.3.1399219850286; Sun, 04 May 2014 09:10:50 -0700 (PDT) Received: from [192.168.1.101] (adsl-99-30-174-168.dsl.sfldmi.sbcglobal.net. [99.30.174.168]) by mx.google.com with ESMTPSA id kq1sm11489392igb.16.2014.05.04.09.10.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 04 May 2014 09:10:49 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-6A00E8D4-4F99-4007-BDDA-BB25B0BE38F2 Mime-Version: 1.0 (1.0) From: Ahmad Muhanna X-Mailer: iPhone Mail (11D201) In-Reply-To: Date: Sun, 4 May 2014 11:10:49 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: To: vijay kn Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/fBGS56ImRlTH0MFFpBbext1WZw0 Cc: "ipsec@ietf.org" , "vijay@wichorus.com" , "kilian.weniger@googlemail.com" , "vjkumar2003@gmail.com" Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 16:10:56 -0000 --Apple-Mail-6A00E8D4-4F99-4007-BDDA-BB25B0BE38F2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Vijay,=20 I am NOT one if the authors of this RFC but I recall the discussion and the u= se case. If I understand the scenario correctly, the client in this case (eN= B) negotiated an IKE SA without indicating the ability to support REDIRECT. I= f that is the case, the client should renegotiate IKE SA after being upgrade= d to support this functionality. My understanding renegotiating IKE SA is su= pported. IMO, I do not think that anything in this RFC needs to be changed. Regards, Ahmad Muhanna=20 > On May 2, 2014, at 9:14 AM, vijay kn wrote: >=20 > Hi, > There is an issue in IKEv2 REDIRECT RFC 5685. In one scenario, the IKEv2 R= EDIRECT will not work indefinitely. > =20 > Scenario: - > Let=E2=80=99s assume there are about 1000 clients connected to a IKEv2 RED= IRECT enabled SeGW. None of the clients were IKEv2 redirect enabled at the t= ime of establishing SA with the SeGW (meaning they have not sent the REDIREC= T_SUPPORTED notification in the > IKE_SA_INIT message) > This will lead to a situation where the SeGW is loaded and wanting to redi= rect some clients to another SeGW but it cannot REDIRECT them as none of the= m have indicated REDIRECT support in the IKE_SA_INIT message. > If the user/operator enabled REDIRECT functionality dynamically (like afte= r SAs were established), then the SeGW is not going to redirect them because= it had not received a REDIRECT_SUPPORTED payload from the clients. > =20 > Effect/Impact: - > This leads to a congestion/overload at the gateway when the base stations c= onnecting to the SeGW are several hundred/thousands in number. In the LTE an= d LTE-A scenarios, this condition is possible where the number of base stati= ons connecting to the SeGW are very high. > =20 > Suggestion/Solution: - > A change is required in RFC 5685 is required as below: - > =E2=80=9C=E2=80=9DWhenever the redirect feature/functionality is enabled a= t run-time, the client should indicate the same to the SeGW. This can be don= e by the client sending an INFORMATIONAL message under the protection of th= e IKE SA. This message MUST have a REDIRECT_SUPPORTED notify payload to enab= le the SeGW to redirect them at run-time even though they had initially conn= ected with SeGW without REDIRECT support=E2=80=9D=E2=80=9D > =20 > Request for comments: - > Please read the problem, impact and solution listed above and let me know i= f any comments. Hope my point is valid and needs to be incorporated as the R= FC update. > =20 > =20 > Regards, > Vijay N. > =20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail-6A00E8D4-4F99-4007-BDDA-BB25B0BE38F2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi, Vijay, 

<= div>I am NOT one if the authors of this RFC but I recall the discussion and t= he use case. If I understand the scenario correctly, the client in this case= (eNB) negotiated an IKE SA without indicating the ability to support REDIRE= CT. If that is the case, the client should renegotiate IKE SA after being up= graded to support this functionality. My understanding renegotiating IKE SA i= s supported.

IMO, I do not think that anything in t= his RFC needs to be changed.

Regards,
Ahmad Muhanna <= /div>

On May 2, 2014, at 9:14 AM, vijay kn <vijay.kn@huawei.com> wrote:

=

Hi,

There is an issue in IK= Ev2 REDIRECT RFC 5685. In one scenario, the IKEv2 REDIRECT will not w= ork indefinitely.

 

Scenario: -

Let=E2=80=99s assume there are about 1000 clients con= nected to a IKEv2 REDIRECT enabled SeGW. None of the clients were IKEv2 redirect enabled at the time of establishi= ng SA with the SeGW (meaning they have not sent the REDIRECT_SUPPORTED n= otification in the

IKE_SA_INIT message)

This will lead to a situation where the SeGW is loade= d and wanting to redirect some clients to another SeGW but it cannot REDIREC= T them as none of them have indicated REDIRECT support in the IKE_SA_INIT me= ssage.

If the user/operator enabled REDIRECT functionality d= ynamically (like after SAs were established), then the SeGW is not going to r= edirect them because it had not received a REDIRECT_SUPPORTED payload from t= he clients.

 

Effect/Impact: -

This leads to a congestion/overload at the gateway wh= en the base stations connecting to the SeGW are several hundred/thousands in= number. In the LTE and LTE-A scenarios, this condition is possible where th= e number of base stations connecting to the SeGW are very high.

 

Suggestion/Solution: -

A change is required in RFC 5685 is required as below= : -

=E2=80=9C=E2=80=9DWhene= ver the redirect feature/functionality is enabled at run-time, the client sh= ould indicate the same to the SeGW. This can be done by the client sending a= n INFORMATIONAL message  under the protection of the IKE SA. This message MUST have a REDIRECT_SUPPORTED notify payload to e= nable the SeGW to redirect them at run-time even though they had initially c= onnected with SeGW without REDIRECT support=E2=80=9D=E2=80=9D

 

Request for comments: -

Please read the problem, impact and solution listed a= bove and let me know if any comments. Hope my point is valid and needs to be= incorporated as the RFC update.

 

 

Regards,

Vijay N.

 

____________________= ___________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mai= lman/listinfo/ipsec
= --Apple-Mail-6A00E8D4-4F99-4007-BDDA-BB25B0BE38F2-- From nobody Sun May 4 21:09:08 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D351A0240 for ; Sun, 4 May 2014 21:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlZ1g2vTZjLR for ; Sun, 4 May 2014 21:09:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F3D9A1A0243 for ; Sun, 4 May 2014 21:09:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGK04784; Mon, 05 May 2014 04:08:58 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 5 May 2014 05:07:27 +0100 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 5 May 2014 05:08:56 +0100 Received: from SZXEML513-MBX.china.huawei.com ([169.254.7.157]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Mon, 5 May 2014 12:08:51 +0800 From: vijay kn To: Yoav Nir Thread-Topic: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) Thread-Index: Ac9mCR4Wj8NaQqRJSGu1iyUmq2WiKQAB4oDwAEWa64AAO+amEA== Date: Mon, 5 May 2014 04:08:50 +0000 Message-ID: References: <22DBA0CE-BF37-48E2-A87D-B1D66E64DE1B@gmail.com> In-Reply-To: <22DBA0CE-BF37-48E2-A87D-B1D66E64DE1B@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.146.58] Content-Type: multipart/alternative; boundary="_000_AD5AD8B0B070044BAD3C37D7057F37E153FE6485szxeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Wur8VRcW7YiJu_zR8EeZk9SAh4Y Cc: "ipsec@ietf.org" , "vijay@wichorus.com" , "kilian.weniger@googlemail.com" , "vjkumar2003@gmail.com" Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 04:09:06 -0000 --_000_AD5AD8B0B070044BAD3C37D7057F37E153FE6485szxeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yoav, Yes your understanding is right. They are disabled by configuration but lat= er enabled may be after tunnel is setup. FYI, it has no relation with roaming. I can see this as a case like: 1) When a base station is initially not REDIRECT enabled but later the= software version is upgraded to the version that has REDIRECT support 2) The base station normally will be REDIRECT disabled because the bas= e station might establish Tunnel with other base stations and/or other SeGW= s which may or may not support REDIRECT. So the config will be disabled by= default. Thanks. From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Sunday, May 04, 2014 12:56 PM To: vijay kn Cc: ipsec@ietf.org; vijay@wichorus.com; kilian.weniger@googlemail.com; vjku= mar2003@gmail.com Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) Hi Vijay I'm no expert on REDIRECT, and my implementation does not support it. Your issue seems to be about implementations that have the REDIRECT functio= nality, but don't advertise as much when they connect to the peer gateway. = So it's as if this feature is disabled by configuration. Am I understanding= this correctly? So my question to you would be why this would make sense. Why do these clie= nts enable and disable the feature during the lifetime on an IKEv2 SA? Why = not leave is always on? Is this some kind of roaming issue? Yoav On May 2, 2014, at 5:14 PM, vijay kn > wrote: Hi, There is an issue in IKEv2 REDIRECT RFC 5685. In one scenario, the IKEv2 RE= DIRECT will not work indefinitely. Scenario: - Let's assume there are about 1000 clients connected to a IKEv2 REDIRECT ena= bled SeGW. None of the clients were IKEv2 redirect enabled at the time of e= stablishing SA with the SeGW (meaning they have not sent the REDIRECT_SUPPO= RTED notification in the IKE_SA_INIT message) This will lead to a situation where the SeGW is loaded and wanting to redir= ect some clients to another SeGW but it cannot REDIRECT them as none of the= m have indicated REDIRECT support in the IKE_SA_INIT message. If the user/operator enabled REDIRECT functionality dynamically (like after= SAs were established), then the SeGW is not going to redirect them because= it had not received a REDIRECT_SUPPORTED payload from the clients. Effect/Impact: - This leads to a congestion/overload at the gateway when the base stations c= onnecting to the SeGW are several hundred/thousands in number. In the LTE a= nd LTE-A scenarios, this condition is possible where the number of base sta= tions connecting to the SeGW are very high. Suggestion/Solution: - A change is required in RFC 5685 is required as below: - ""Whenever the redirect feature/functionality is enabled at run-time, the c= lient should indicate the same to the SeGW. This can be done by the client = sending an INFORMATIONAL message under the protection of the IKE SA. This = message MUST have a REDIRECT_SUPPORTED notify payload to enable the SeGW to= redirect them at run-time even though they had initially connected with Se= GW without REDIRECT support"" Request for comments: - Please read the problem, impact and solution listed above and let me know i= f any comments. Hope my point is valid and needs to be incorporated as the = RFC update. Regards, Vijay N. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_AD5AD8B0B070044BAD3C37D7057F37E153FE6485szxeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yoav,

Yes your understanding is= right. They are disabled by configuration but later enabled may be after t= unnel is setup.

FYI, it has no relation w= ith roaming.

 <= /p>

I can see this as a case = like:

1) = ;     When a base stati= on is initially not REDIRECT enabled but later the software version is upgr= aded to the version that has REDIRECT support

2) = ;     The base station = normally will be REDIRECT disabled because the base station might establish= Tunnel with other base stations and/or other SeGWs which may or may not support  REDIRECT. So the config will be disabled by d= efault.

 <= /p>

 <= /p>

 <= /p>

Thanks.=

 <= /p>

From: IPsec [m= ailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir
Sent: Sunday, May 04, 2014 12:56 PM
To: vijay kn
Cc: ipsec@ietf.org; vijay@wichorus.com; kilian.weniger@googlemail.co= m; vjkumar2003@gmail.com
Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC= 5685)

 

Hi Vijay

 

I’m no expert on REDIRECT, and my implementati= on does not support it. 

 

Your issue seems to be about implementations that ha= ve the REDIRECT functionality, but don’t advertise as much when they = connect to the peer gateway. So it’s as if this feature is disabled b= y configuration. Am I understanding this correctly?  

 

So my question to you would be why this would make s= ense. Why do these clients enable and disable the feature during the lifeti= me on an IKEv2 SA? Why not leave is always on?

 

Is this some kind of roaming issue?

 

Yoav

 

On May 2, 2014, at 5:14 PM, vijay kn <vijay.kn@huawei.com> wrote:



Hi,

There is an issue in IKEv2 REDIREC= T RFC 5685. In one scenario, the IKEv2 REDIRECT will not work indefinitely.

 

Scenario: -<= o:p>

Let’s assume there are about 1000= clients connected to a IKEv2 REDIRECT enabled SeGW. None of the clients were IKEv2 redirect enabled at the time of establishing SA with the SeGW (meaning they have not sent the REDIRECT_S= UPPORTED notification in the

IKE_SA_INIT message)<= /p>

This will lead to a situation where the= SeGW is loaded and wanting to redirect some clients to another SeGW but it= cannot REDIRECT them as none of them have indicated REDIRECT support in the IKE_SA_INIT message.

If the user/operator enabled REDIRECT f= unctionality dynamically (like after SAs were established), then the SeGW i= s not going to redirect them because it had not received a REDIRECT_SUPPORTED payload from the clients.

 

Effect/Impact: -

This leads to a congestion/overload at = the gateway when the base stations connecting to the SeGW are several hundr= ed/thousands in number. In the LTE and LTE-A scenarios, this condition is possible where the number of base stations connecting to= the SeGW are very high.

 

Suggestion/Solution: -

A change is required in RFC 5685 is req= uired as below: -

“”Whenever th= e redirect feature/functionality is enabled at run-time, the client should = indicate the same to the SeGW. This can be done by the client sending an INFORMATIONAL message  under the protection of the IKE SA. This me= ssage MUST have a REDIRECT_SUPPORTED notify payload to enable the SeGW to r= edirect them at run-time even though they had initially connected with SeGW= without REDIRECT support””

 

Request for comments: -

Please read the problem, impact and sol= ution listed above and let me know if any comments. Hope my point is valid = and needs to be incorporated as the RFC update.

 

 

Regards,

Vijay N.

 

______________________________________= _________
IPsec mailing list
IPsec@ietf.o= rg
https://www.ietf.org/mailman/listinfo/ipsec=

 

--_000_AD5AD8B0B070044BAD3C37D7057F37E153FE6485szxeml513mbxchi_-- From nobody Sun May 4 21:53:46 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710CE1A0243 for ; Sun, 4 May 2014 21:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSQ3VGDJHWQv for ; Sun, 4 May 2014 21:53:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB0E1A0246 for ; Sun, 4 May 2014 21:53:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGK07388; Mon, 05 May 2014 04:53:35 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 5 May 2014 05:52:02 +0100 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 5 May 2014 05:53:31 +0100 Received: from szxeml561-mbx.china.huawei.com ([169.254.5.235]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Mon, 5 May 2014 12:53:27 +0800 From: Syed Ajim Hussain To: Yoav Nir Thread-Topic: [IPsec] Simultaneous Child SA Creation tigger from both the side. Thread-Index: AQHPZ2khmcBXGvz+XEGVooQR1v79VpsxaMUQ Date: Mon, 5 May 2014 04:53:27 +0000 Message-ID: <335B84BDA2818C428E63D9B0ADE6863545AF7A1A@szxeml561-mbx.china.huawei.com> References: <335B84BDA2818C428E63D9B0ADE6863545AF7228@szxeml561-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.144.132] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/3FkVt7AnbAVfhMQzhGSpc2zdfsw Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Simultaneous Child SA Creation tigger from both the side. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 04:53:42 -0000 SGkgWW9hdiAgDQogICAgICAgVGhhbmtzIGZvciB5b3VyIHJlcGx5LCBUaGlzIHByb2JsZW0gaGFw cGVuZWQgaW4gcmVhbCBzY2VuYXJpbywgIHByb2JsZW0gaXMtICBib3RoIHRoZSBUdW5uZWwgZW5k IHBvaW50cyBhcmUgZGlmZmVyZW50IHZlbmRvciwgDQogICAgICAgVGhleSBoYW5kbGUgaXQgZGlm ZmVyZW50bHkuICAgIA0KDQogICAgICAgV2UgY2FuIGRlZmluZWQgdGhpcyBiZWhhdmlvciBpbiBS RkMsDQoNCiAgICAgICBBbHNvIHdlIGhhdmUgc29tZSBvdGhlciBzY2VuYXJpb3MsIGl0IHdpbGwg YmUgYmV0dGVyIGlmIHdlIGRlZmluZSB0aGVzZSBleHRyZW1lIGNhc2UgYmVoYXZpb3IgYWxzbyBp biBSRkMsIA0KICAgICAgIHRvIG1ha2UgaW50ZXItb3Agc21vb3RoLiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQoNCldpdGggUmVnYXJkcw0KU3llZCBBamltIA0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogWW9hdiBOaXIgW21haWx0bzp5bmlyLmll dGZAZ21haWwuY29tXSANClNlbnQ6IDIwMTTE6jXUwjTI1SAxMjo0OQ0KVG86IFN5ZWQgQWppbSBI dXNzYWluDQpDYzogaXBzZWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSVBzZWNdIFNpbXVsdGFu ZW91cyBDaGlsZCBTQSBDcmVhdGlvbiB0aWdnZXIgZnJvbSBib3RoIHRoZSBzaWRlLg0KDQpIaQ0K DQpUaGUgcmVhc29uIHRoYXQgd2UgZG9uoa90IGhhdmUgYW55IG1lbnRpb24gb2Ygc2ltdWx0YW5l b3VzIFNBIGNyZWF0aW9uIGlzIHRoYXQgdGhpcyBpc3N1ZSBoYXMgbm90IGNvbWUgdXAgaW4gcHJh Y3RpY2UuICBXaGVuIHR3byBJUHNlYyBob3N0cyBkb26hr3QgaGF2ZSBhbiBTQSBmb3IgYSBwYXJ0 aWN1bGFyIGZsb3cgKGJlY2F1c2Ugc2FpZCBmbG93IGhhc26hr3QgaGFkIHRyYWZmaWMgaW4gYSB3 aGlsZSksIGl0oa9zIGhpZ2hseSB1bmxpa2VseSB0aGF0IGJpZGlyZWN0aW9uYWwgdHJhZmZpYyBv biB0aGlzIGZsb3cgd2lsbCBiZWdpbiBzaW11bHRhbmVvdXNseSwgb3IgYXQgbGVhc3QgYmVmb3Jl IHRoZSAxLTIgcm91bmR0cmlwcyBpdCB0YWtlcyB0byBzZXQgdXAgYSBjaGlsZCBTQS4NCg0KT24g dGhlIG90aGVyIGhhbmQsIHdoZW4gU0EgbGlmZXRpbWVzIGFyZSBzZXQgYW5kIHRyYWZmaWMgaXMg Y29udGludW91cywgaXShr3MgdmVyeSBsaWtlbHkgdGhhdCB0d28gc3VjaCBpbXBsZW1lbnRhdGlv bnMgd2lsbCBiZWdpbiBhIHJla2V5aW5nIGF0IHRoZSBzYW1lIHRpbWUuDQoNClNvIHdoYXQgd291 bGQgaGFwcGVuPyAgQm90aCBpbXBsZW1lbnRhdGlvbnMgZ2V0IGEgQ3JlYXRlQ2hpbGRTQSByZXF1 ZXN0IChvciBhbiBJS0VfQVVUSCByZXF1ZXN0KSBhZnRlciBlYWNoIGhhcyBzZW50IG91dCBpdHMg b3duIHJlcXVlc3QuIEkgZ3Vlc3Mgd2UgY291bGQgc3BlY2lmeSBpdCB0aGUgc2FtZSB3YXkgYXMg aW4gc2VjdGlvbiAyLjguMSwgYnV0IGRvaW5nIHRoaXMgd291bGQgYmUgYSBwcm9ibGVtIGJlY2F1 c2UgdGhpcyBpcyBub3Qgc3BlY2lmaWVkIGFuZCBvdGhlciBpbXBsZW1lbnRhdGlvbnMgYXJlIGxp a2VseSBub3QgdG8gZG8gaXQuDQoNClNvcnJ5IEkgZG9uoa90IGhhdmUgYSBiZXR0ZXIgYW5zd2Vy IGZvciB5b3UuDQoNCllvYXYNCg0KT24gTWF5IDIsIDIwMTQsIGF0IDM6MjcgUE0sIFN5ZWQgQWpp bSBIdXNzYWluIDxzeWVkYWhAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCj4gSGkgQWxsLiANCj4gDQo+ ICAgICAgICBIb3N0IEEgLS0tLS0tLS0tLS0tLS1Ib3N0IEIgIA0KPiANCj4gICAgQXNzdW1lICBI b3N0LUEgJiBIb3N0LUIgd2FudCB0byBlc3RhYmxpc2hlZCBJUFNFQyBUdW5uZWwsIEZpcnN0IHRo ZXkgZXN0YWJsaXNoZWQgb25lIElLRSBTQSBhbmQgIG9uZSBJUFNFQyBTQSAoQ2hpbGQgU0EpLiAg ICANCj4gDQo+ICAgIEFmdGVyIHRoYXQgZHVlIHRvIGFkZGl0aW9uIG9mIGEgbmV3IElQU0VDIFBv bGljeShTUEQpLCAgQm90aCB0aGUgc2lkZXMgdHJpZ2dlcmVkIG9uZSBtb3JlIENoaWxkICBTQSBj cmVhdGlvbi4gDQo+IA0KPiAgICBUaGlzIENoaWxkIFNBIGNyZWF0aW9uIGhpdCBzaW11bHRhbmVv dXMgQ2hpbGQgU0EgQ3JlYXRpb24gY29uZGl0aW9uLiBTaW5jZSBib3RoIHRoZSBzaWRlIHRyaWdn ZXJlZCBmb3IgIENoaWxkIFNBICAgDQo+ICAgIENyZWF0aW9uIGZvciBvbmUgQ29uZmlndXJlZCBT UEQgKFRyYWZmaWMgRmxvdykuIA0KPiANCj4gICAgSW4gUkZDIDU5OTYgLCB0aGVyZSBpcyBubyBw b2ludCBtZW50aW9uIGFib3V0IHNpbXVsdGFuZW91cyBleGNoYW5nZSBkdXJpbmcgIENoaWxkIFNB IGNyZWF0ZSwgaXQgb25seSBtZW50aW9uIFNpbXVsdGFuZW91cyANCj4gICAgSGFuZGxpbmcgZHVy aW5nIENoaWxkIFNBIFJla2V5LiAgICAgICAgICAgICAgIA0KPiANCj4gICAgV2hhdCBzaG91bGQg YmUgdGhlIGJlaGF2aW9yIGluIGNhc2Ugb2YgU2ltdWx0YW5lb3VzICBDaGlsZCBTQSBDcmVhdGlv biwgaWYgaW1wbGVtZW50YXRpb24gbWFpbnRhaW4gb25lIENoaWxkIFNBIHBlciBvbmUgVHJhZmZp YyBGbG93IChTUEQpLiAgDQo+IA0KPiAgICBEb2VzICBTaW11bHRhbmVvdXMgQ2hpbGQgU0EgUmVr ZXlpbmcgLSBtZXRob2QgYWxzbyBhcHBsaWNhYmxlIGluIGNhc2Ugb2YgQ2hpbGQgU0EgQ3JlYXRp b24gKG5vdCBSZWtleSkuICAgICAgICAgIA0KPiANCj4gDQo+IDIuOC4xLiAgU2ltdWx0YW5lb3Vz IENoaWxkIFNBIFJla2V5aW5nDQo+IA0KPiAgIElmIHRoZSB0d28gZW5kcyBoYXZlIHRoZSBzYW1l IGxpZmV0aW1lIHBvbGljaWVzLCBpdCBpcyBwb3NzaWJsZSB0aGF0DQo+ICAgYm90aCB3aWxsIGlu aXRpYXRlIGEgcmVrZXlpbmcgYXQgdGhlIHNhbWUgdGltZSAod2hpY2ggd2lsbCByZXN1bHQgaW4N Cj4gICByZWR1bmRhbnQgU0FzKS4gIFRvIHJlZHVjZSB0aGUgcHJvYmFiaWxpdHkgb2YgdGhpcyBo YXBwZW5pbmcsIHRoZQ0KPiAgIHRpbWluZyBvZiByZWtleWluZyByZXF1ZXN0cyBTSE9VTEQgYmUg aml0dGVyZWQgKGRlbGF5ZWQgYnkgYSByYW5kb20NCj4gICBhbW91bnQgb2YgdGltZSBhZnRlciB0 aGUgbmVlZCBmb3IgcmVrZXlpbmcgaXMgbm90aWNlZCkuDQo+IA0KPiANCj4gDQo+IA0KPiBLYXVm bWFuLCBldCBhbC4gICAgICAgICAgICAgIFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAg ICBbUGFnZSAzNl0NCj4gDQo+IFJGQyA1OTk2ICAgICAgICAgICAgICAgICAgICAgICAgSUtFdjJi aXMgICAgICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAxMA0KPiANCj4gDQo+ICAgVGhpcyBmb3Jt IG9mIHJla2V5aW5nIG1heSB0ZW1wb3JhcmlseSByZXN1bHQgaW4gbXVsdGlwbGUgc2ltaWxhciBT QXMNCj4gICBiZXR3ZWVuIHRoZSBzYW1lIHBhaXJzIG9mIG5vZGVzLiAgV2hlbiB0aGVyZSBhcmUg dHdvIFNBcyBlbGlnaWJsZSB0bw0KPiAgIHJlY2VpdmUgcGFja2V0cywgYSBub2RlIE1VU1QgYWNj ZXB0IGluY29taW5nIHBhY2tldHMgdGhyb3VnaCBlaXRoZXINCj4gICBTQS4gIElmIHJlZHVuZGFu dCBTQXMgYXJlIGNyZWF0ZWQgdGhvdWdoIHN1Y2ggYSBjb2xsaXNpb24sIHRoZSBTQQ0KPiAgIGNy ZWF0ZWQgd2l0aCB0aGUgbG93ZXN0IG9mIHRoZSBmb3VyIG5vbmNlcyB1c2VkIGluIHRoZSB0d28g ZXhjaGFuZ2VzDQo+ICAgU0hPVUxEIGJlIGNsb3NlZCBieSB0aGUgZW5kcG9pbnQgdGhhdCBjcmVh dGVkIGl0LiAgIkxvd2VzdCIgbWVhbnMgYW4NCj4gICBvY3RldC1ieS1vY3RldCBjb21wYXJpc29u IChpbnN0ZWFkIG9mLCBmb3IgaW5zdGFuY2UsIGNvbXBhcmluZyB0aGUNCj4gICBub25jZXMgYXMg bGFyZ2UgaW50ZWdlcnMpLiAgSW4gb3RoZXIgd29yZHMsIHN0YXJ0IGJ5IGNvbXBhcmluZyB0aGUN Cj4gICBmaXJzdCBvY3RldDsgaWYgdGhleSdyZSBlcXVhbCwgbW92ZSB0byB0aGUgbmV4dCBvY3Rl dCwgYW5kIHNvIG9uLiAgSWYNCj4gICB5b3UgcmVhY2ggdGhlIGVuZCBvZiBvbmUgbm9uY2UsIHRo YXQgbm9uY2UgaXMgdGhlIGxvd2VyIG9uZS4gIFRoZQ0KPiAgIG5vZGUgdGhhdCBpbml0aWF0ZWQg dGhlIHN1cnZpdmluZyByZWtleWVkIFNBIHNob3VsZCBkZWxldGUgdGhlDQo+ICAgcmVwbGFjZWQg U0EgYWZ0ZXIgdGhlIG5ldyBvbmUgaXMgZXN0YWJsaXNoZWQuDQo+IA0KPiAgIFRoZSBmb2xsb3dp bmcgaXMgYW4gZXhwbGFuYXRpb24gb24gdGhlIGltcGFjdCB0aGlzIGhhcyBvbg0KPiAgIGltcGxl bWVudGF0aW9ucy4gIEFzc3VtZSB0aGF0IGhvc3RzIEEgYW5kIEIgaGF2ZSBhbiBleGlzdGluZyBD aGlsZCBTQQ0KPiAgIHBhaXIgd2l0aCBTUElzIChTUElhMSxTUEliMSksIGFuZCBib3RoIHN0YXJ0 IHJla2V5aW5nIGl0IGF0IHRoZSBzYW1lDQo+ICAgdGltZToNCj4gDQo+ICAgSG9zdCBBICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEhvc3QgQg0KPiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gICBzZW5kIHJl cTE6IE4oUkVLRVlfU0EsU1BJYTEpLA0KPiAgICAgICBTQSguLixTUElhMiwuLiksTmkxLC4uICAt LT4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwtLSAgc2VuZCByZXEyOiBOKFJF S0VZX1NBLFNQSWIxKSwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFNBKC4uLFNQSWIyLC4uKSxOaTINCj4gICByZWN2IHJlcTIgPC0tDQo+IA0KPiAgIEF0IHRoaXMg cG9pbnQsIEEga25vd3MgdGhlcmUgaXMgYSBzaW11bHRhbmVvdXMgcmVrZXlpbmcgaGFwcGVuaW5n Lg0KPiAgIEhvd2V2ZXIsIGl0IGNhbm5vdCB5ZXQga25vdyB3aGljaCBvZiB0aGUgZXhjaGFuZ2Vz IHdpbGwgaGF2ZSB0aGUNCj4gICBsb3dlc3Qgbm9uY2UsIHNvIGl0IHdpbGwganVzdCBub3RlIHRo ZSBzaXR1YXRpb24gYW5kIHJlc3BvbmQgYXMNCj4gICB1c3VhbC4NCj4gDQo+ICAgc2VuZCByZXNw MjogU0EoLi4sU1BJYTMsLi4pLA0KPiAgICAgICAgTnIxLC4uICAtLT4NCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC0tPiAgcmVjdiByZXExDQo+IA0KPiAgIE5vdyBCIGFsc28ga25v d3MgdGhhdCBzaW11bHRhbmVvdXMgcmVrZXlpbmcgaXMgZ29pbmcgb24uICBJdCByZXNwb25kcw0K PiAgIGFzIHVzdWFsLg0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tICBz ZW5kIHJlc3AxOiBTQSguLixTUEliMywuLiksDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE5yMiwuLg0KPiAgIHJlY3YgcmVzcDEgPC0tDQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tPiAgcmVjdiByZXNwMg0KPiANCj4gICBBdCB0aGlzIHBvaW50LCB0 aGVyZSBhcmUgdGhyZWUgQ2hpbGQgU0EgcGFpcnMgYmV0d2VlbiBBIGFuZCBCICh0aGUNCj4gICBv bGQgb25lIGFuZCB0d28gbmV3IG9uZXMpLiAgQSBhbmQgQiBjYW4gbm93IGNvbXBhcmUgdGhlIG5v bmNlcy4NCj4gICBTdXBwb3NlIHRoYXQgdGhlIGxvd2VzdCBub25jZSB3YXMgTnIxIGluIG1lc3Nh Z2UgcmVzcDI7IGluIHRoaXMgY2FzZSwNCj4gICBCICh0aGUgc2VuZGVyIG9mIHJlcTIpIGRlbGV0 ZXMgdGhlIHJlZHVuZGFudCBuZXcgU0EsIGFuZCBBICh0aGUgbm9kZQ0KPiAgIHRoYXQgaW5pdGlh dGVkIHRoZSBzdXJ2aXZpbmcgcmVrZXllZCBTQSksIGRlbGV0ZXMgdGhlIG9sZCBvbmUuDQo+IA0K PiANCj4gDQo+IEthdWZtYW4sIGV0IGFsLiAgICAgICAgICAgICAgU3RhbmRhcmRzIFRyYWNrICAg ICAgICAgICAgICAgICAgIFtQYWdlIDM3XQ0KPiANCj4gUkZDIDU5OTYgICAgICAgICAgICAgICAg ICAgICAgICBJS0V2MmJpcyAgICAgICAgICAgICAgICAgIFNlcHRlbWJlciAyMDEwDQo+IA0KPiAN Cj4gICBzZW5kIHJlcTM6IEQoU1BJYTEpIC0tPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPC0tICBzZW5kIHJlcTQ6IEQoU1BJYjIpDQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAtLT4gIHJlY3YgcmVxMw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PC0tICBzZW5kIHJlc3AzOiBEKFNQSWIxKQ0KPiAgIHJlY3YgcmVxNCA8LS0NCj4gICBzZW5kIHJl c3A0OiBEKFNQSWEzKSAtLT4NCj4gDQo+ICAgVGhlIHJla2V5aW5nIGlzIG5vdyBmaW5pc2hlZC4N Cj4gDQo+ICAgSG93ZXZlciwgdGhlcmUgaXMgYSBzZWNvbmQgcG9zc2libGUgc2VxdWVuY2Ugb2Yg ZXZlbnRzIHRoYXQgY2FuDQo+ICAgaGFwcGVuIGlmIHNvbWUgcGFja2V0cyBhcmUgbG9zdCBpbiB0 aGUgbmV0d29yaywgcmVzdWx0aW5nIGluDQo+ICAgcmV0cmFuc21pc3Npb25zLiAgVGhlIHJla2V5 aW5nIGJlZ2lucyBhcyB1c3VhbCwgYnV0IEEncyBmaXJzdCBwYWNrZXQNCj4gICAocmVxMSkgaXMg bG9zdC4NCj4gDQo+ICAgSG9zdCBBICAgICAgICAgICAgICAgICAgICAgICAgICAgIEhvc3QgQg0K PiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gICBzZW5kIHJlcTE6IE4oUkVLRVlfU0EsU1BJYTEpLA0KPiAgICAg ICBTQSguLixTUElhMiwuLiksDQo+ICAgICAgIE5pMSwuLiAgLS0+ICAobG9zdCkNCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDwtLSAgc2VuZCByZXEyOiBOKFJFS0VZX1NBLFNQSWIx KSwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNBKC4uLFNQSWIy LC4uKSxOaTINCj4gICByZWN2IHJlcTIgPC0tDQo+ICAgc2VuZCByZXNwMjogU0EoLi4sU1BJYTMs Li4pLA0KPiAgICAgICBOcjEsLi4gLS0+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAtLT4gIHJlY3YgcmVzcDINCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwtLSAg c2VuZCByZXEzOiBEKFNQSWIxKQ0KPiAgIHJlY3YgcmVxMyA8LS0NCj4gICBzZW5kIHJlc3AzOiBE KFNQSWExKSAtLT4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tPiAgcmVjdiBy ZXNwMw0KPiANCj4gICBGcm9tIEIncyBwb2ludCBvZiB2aWV3LCB0aGUgcmVrZXlpbmcgaXMgbm93 IGNvbXBsZXRlZCwgYW5kIHNpbmNlIGl0DQo+ICAgaGFzIG5vdCB5ZXQgcmVjZWl2ZWQgQSdzIHJl cTEsIGl0IGRvZXMgbm90IGV2ZW4ga25vdyB0aGF0IHRoZXJlIHdhcw0KPiAgIHNpbXVsdGFuZW91 cyByZWtleWluZy4gIEhvd2V2ZXIsIEEgd2lsbCBjb250aW51ZSByZXRyYW5zbWl0dGluZyB0aGUN Cj4gICBtZXNzYWdlLCBhbmQgZXZlbnR1YWxseSBpdCB3aWxsIHJlYWNoIEIuDQo+IA0KPiAgIHJl c2VuZCByZXExIC0tPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0+ICByZWN2 IHJlcTENCj4gDQo+ICAgVG8gQiwgaXQgbG9va3MgbGlrZSBBIGlzIHRyeWluZyB0byByZWtleSBh biBTQSB0aGF0IG5vIGxvbmdlciBleGlzdHM7DQo+ICAgdGh1cywgQiByZXNwb25kcyB0byB0aGUg cmVxdWVzdCB3aXRoIHNvbWV0aGluZyBub24tZmF0YWwgc3VjaCBhcw0KPiAgIENISUxEX1NBX05P VF9GT1VORC4NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LS0gIHNlbmQg cmVzcDE6IE4oQ0hJTERfU0FfTk9UX0ZPVU5EKQ0KPiAgIHJlY3YgcmVzcDEgPC0tDQo+IA0KPiAg IFdoZW4gQSByZWNlaXZlcyB0aGlzIGVycm9yLCBpdCBhbHJlYWR5IGtub3dzIHRoZXJlIHdhcyBz aW11bHRhbmVvdXMNCj4gICByZWtleWluZywgc28gaXQgY2FuIGlnbm9yZSB0aGUgZXJyb3IgbWVz c2FnZQ0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IElQc2VjIG1haWxpbmcgbGlzdA0KPiBJUHNlY0BpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQoNCg== From nobody Sun May 4 22:33:19 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7401A0254 for ; Sun, 4 May 2014 22:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kueX3DtKVMy1 for ; Sun, 4 May 2014 22:33:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3391A0250 for ; Sun, 4 May 2014 22:33:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDV03578; Mon, 05 May 2014 05:33:10 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 5 May 2014 06:31:05 +0100 Received: from SZXEML455-HUB.china.huawei.com (10.82.67.198) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 5 May 2014 06:32:35 +0100 Received: from SZXEML513-MBX.china.huawei.com ([169.254.7.157]) by SZXEML455-HUB.china.huawei.com ([10.82.67.198]) with mapi id 14.03.0158.001; Mon, 5 May 2014 13:30:03 +0800 From: vijay kn To: Ahmad Muhanna Thread-Topic: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) Thread-Index: Ac9mCR4Wj8NaQqRJSGu1iyUmq2WiKQAB4oDwAFfs6YAALHiKIA== Date: Mon, 5 May 2014 05:30:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.146.58] Content-Type: multipart/alternative; boundary="_000_AD5AD8B0B070044BAD3C37D7057F37E153FE64F9szxeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/qf9rpzD55pqo_9QjyCQjX0yMO48 Cc: "ipsec@ietf.org" , "vijay@wichorus.com" , "kilian.weniger@googlemail.com" , "vjkumar2003@gmail.com" Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 05:33:18 -0000 --_000_AD5AD8B0B070044BAD3C37D7057F37E153FE64F9szxeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWhtYWQsDQpJZiB5b3UgbWVhbnQgcmUtbmVnb3RpYXRpbmcgaXMgSUtFdjIgcmVrZXkgdGhl biBpdCB3aWxsIG5vdCB3b3JrIGJlY2F1c2UgSUtFdjIgcmVrZXkgd2lsbCBub3Qgc2VuZCBhbnkg SUtFX1NBX0lOSVQgcGFja2V0LiBBcyBvZiBub3csIHRoZSBSRkMgc2F5cyB0aGF0IFJFRElSRUNU X1NVUFBPUlRFRCBwYXlsb2FkIGNhbiBiZSBzZW50IG9ubHkgaW4gSUtFX1NBX0lOSVQgbXNnLg0K T1INCklmIHlvdSBtZWFudCByZS1uZWdvdGlhdGluZyBpcyBjb21wbGV0ZWx5IGRlbGV0ZSB0aGUg Y3VycmVudCBTQSBhbmQgcmUtbmVnb3RpYXRlIHRoZSBTQSBmcm9tIHNjcmF0Y2gsIHRoaXMgd291 bGQgbGVhZCB0byBzZXJ2aWNlIGxvc3MvcGt0IGxvc3MuDQoNClJlY29tbWVuZGF0aW9uOiAtDQpT aW5jZSB0aGUgYmFzZSBzdGF0aW9ucyBub3JtYWxseSBlc3RhYmxpc2ggVHVubmVsIHdpdGggb3Ro ZXIgdmVuZG9yIGJhc2Ugc3RhdGlvbnMgYW5kL29yIG90aGVyIHZlbmRvciBHYXRld2F5cyB3aGlj aCBtYXkgb3IgbWF5IG5vdCBzdXBwb3J0ICBSRURJUkVDVCwgaXQgaXMgYmV0dGVyIHRvIGFkZCB0 aGlzIHNvbHV0aW9uIChjbGllbnQgdG8gc2VuZCBhIG5ldyBJTkZPIG1zZyB3aXRoIHRoZSBSRURJ UkVDVF9TVVBQT1JURUQgbm90aWZ5IHBheWxvYWQpIHRvIGVuYWJsZSBhIFNNT09USCBpbnRlci1v cCB3aXRoIG90aGVyIHZlbmRvciBpbXBsZW1lbnRhdGlvbnMuDQoNCkJlY2F1c2Ugb2YgdGhlc2Ug cmVhc29ucywgSSBmZWVsIHRoZSBSRkMgbmVlZHMgY29ycmVjdGlvbi4NCg0KDQpGcm9tOiBBaG1h ZCBNdWhhbm5hIFttYWlsdG86YXNtdWhhbm5hQGdtYWlsLmNvbV0NClNlbnQ6IFN1bmRheSwgTWF5 IDA0LCAyMDE0IDk6NDEgUE0NClRvOiB2aWpheSBrbg0KQ2M6IHZpamF5QHdpY2hvcnVzLmNvbTsg a2lsaWFuLndlbmlnZXJAZ29vZ2xlbWFpbC5jb207IGlwc2VjQGlldGYub3JnOyB2amt1bWFyMjAw M0BnbWFpbC5jb20NClN1YmplY3Q6IFJlOiBbSVBzZWNdIFJlZ2FyZGluZyBJS0V2MiBSRURJUkVD VCBwcm9ibGVtIChyZWZlcmVuY2UgUkZDIDU2ODUpDQoNCkhpLCBWaWpheSwNCg0KSSBhbSBOT1Qg b25lIGlmIHRoZSBhdXRob3JzIG9mIHRoaXMgUkZDIGJ1dCBJIHJlY2FsbCB0aGUgZGlzY3Vzc2lv biBhbmQgdGhlIHVzZSBjYXNlLiBJZiBJIHVuZGVyc3RhbmQgdGhlIHNjZW5hcmlvIGNvcnJlY3Rs eSwgdGhlIGNsaWVudCBpbiB0aGlzIGNhc2UgKGVOQikgbmVnb3RpYXRlZCBhbiBJS0UgU0Egd2l0 aG91dCBpbmRpY2F0aW5nIHRoZSBhYmlsaXR5IHRvIHN1cHBvcnQgUkVESVJFQ1QuIElmIHRoYXQg aXMgdGhlIGNhc2UsIHRoZSBjbGllbnQgc2hvdWxkIHJlbmVnb3RpYXRlIElLRSBTQSBhZnRlciBi ZWluZyB1cGdyYWRlZCB0byBzdXBwb3J0IHRoaXMgZnVuY3Rpb25hbGl0eS4gTXkgdW5kZXJzdGFu ZGluZyByZW5lZ290aWF0aW5nIElLRSBTQSBpcyBzdXBwb3J0ZWQuDQoNCklNTywgSSBkbyBub3Qg dGhpbmsgdGhhdCBhbnl0aGluZyBpbiB0aGlzIFJGQyBuZWVkcyB0byBiZSBjaGFuZ2VkLg0KDQpS ZWdhcmRzLA0KQWhtYWQgTXVoYW5uYQ0KDQpPbiBNYXkgMiwgMjAxNCwgYXQgOToxNCBBTSwgdmlq YXkga24gPHZpamF5LmtuQGh1YXdlaS5jb208bWFpbHRvOnZpamF5LmtuQGh1YXdlaS5jb20+PiB3 cm90ZToNCkhpLA0KVGhlcmUgaXMgYW4gaXNzdWUgaW4gSUtFdjIgUkVESVJFQ1QgUkZDIDU2ODUu IEluIG9uZSBzY2VuYXJpbywgdGhlIElLRXYyIFJFRElSRUNUIHdpbGwgbm90IHdvcmsgaW5kZWZp bml0ZWx5Lg0KDQpTY2VuYXJpbzogLQ0KTGV04oCZcyBhc3N1bWUgdGhlcmUgYXJlIGFib3V0IDEw MDAgY2xpZW50cyBjb25uZWN0ZWQgdG8gYSBJS0V2MiBSRURJUkVDVCBlbmFibGVkIFNlR1cuIE5v bmUgb2YgdGhlIGNsaWVudHMgd2VyZSBJS0V2MiByZWRpcmVjdCBlbmFibGVkIGF0IHRoZSB0aW1l IG9mIGVzdGFibGlzaGluZyBTQSB3aXRoIHRoZSBTZUdXIChtZWFuaW5nIHRoZXkgaGF2ZSBub3Qg c2VudCB0aGUgUkVESVJFQ1RfU1VQUE9SVEVEIG5vdGlmaWNhdGlvbiBpbiB0aGUNCklLRV9TQV9J TklUIG1lc3NhZ2UpDQpUaGlzIHdpbGwgbGVhZCB0byBhIHNpdHVhdGlvbiB3aGVyZSB0aGUgU2VH VyBpcyBsb2FkZWQgYW5kIHdhbnRpbmcgdG8gcmVkaXJlY3Qgc29tZSBjbGllbnRzIHRvIGFub3Ro ZXIgU2VHVyBidXQgaXQgY2Fubm90IFJFRElSRUNUIHRoZW0gYXMgbm9uZSBvZiB0aGVtIGhhdmUg aW5kaWNhdGVkIFJFRElSRUNUIHN1cHBvcnQgaW4gdGhlIElLRV9TQV9JTklUIG1lc3NhZ2UuDQpJ ZiB0aGUgdXNlci9vcGVyYXRvciBlbmFibGVkIFJFRElSRUNUIGZ1bmN0aW9uYWxpdHkgZHluYW1p Y2FsbHkgKGxpa2UgYWZ0ZXIgU0FzIHdlcmUgZXN0YWJsaXNoZWQpLCB0aGVuIHRoZSBTZUdXIGlz IG5vdCBnb2luZyB0byByZWRpcmVjdCB0aGVtIGJlY2F1c2UgaXQgaGFkIG5vdCByZWNlaXZlZCBh IFJFRElSRUNUX1NVUFBPUlRFRCBwYXlsb2FkIGZyb20gdGhlIGNsaWVudHMuDQoNCkVmZmVjdC9J bXBhY3Q6IC0NClRoaXMgbGVhZHMgdG8gYSBjb25nZXN0aW9uL292ZXJsb2FkIGF0IHRoZSBnYXRl d2F5IHdoZW4gdGhlIGJhc2Ugc3RhdGlvbnMgY29ubmVjdGluZyB0byB0aGUgU2VHVyBhcmUgc2V2 ZXJhbCBodW5kcmVkL3Rob3VzYW5kcyBpbiBudW1iZXIuIEluIHRoZSBMVEUgYW5kIExURS1BIHNj ZW5hcmlvcywgdGhpcyBjb25kaXRpb24gaXMgcG9zc2libGUgd2hlcmUgdGhlIG51bWJlciBvZiBi YXNlIHN0YXRpb25zIGNvbm5lY3RpbmcgdG8gdGhlIFNlR1cgYXJlIHZlcnkgaGlnaC4NCg0KU3Vn Z2VzdGlvbi9Tb2x1dGlvbjogLQ0KQSBjaGFuZ2UgaXMgcmVxdWlyZWQgaW4gUkZDIDU2ODUgaXMg cmVxdWlyZWQgYXMgYmVsb3c6IC0NCuKAnOKAnVdoZW5ldmVyIHRoZSByZWRpcmVjdCBmZWF0dXJl L2Z1bmN0aW9uYWxpdHkgaXMgZW5hYmxlZCBhdCBydW4tdGltZSwgdGhlIGNsaWVudCBzaG91bGQg aW5kaWNhdGUgdGhlIHNhbWUgdG8gdGhlIFNlR1cuIFRoaXMgY2FuIGJlIGRvbmUgYnkgdGhlIGNs aWVudCBzZW5kaW5nIGFuIElORk9STUFUSU9OQUwgbWVzc2FnZSAgdW5kZXIgdGhlIHByb3RlY3Rp b24gb2YgdGhlIElLRSBTQS4gVGhpcyBtZXNzYWdlIE1VU1QgaGF2ZSBhIFJFRElSRUNUX1NVUFBP UlRFRCBub3RpZnkgcGF5bG9hZCB0byBlbmFibGUgdGhlIFNlR1cgdG8gcmVkaXJlY3QgdGhlbSBh dCBydW4tdGltZSBldmVuIHRob3VnaCB0aGV5IGhhZCBpbml0aWFsbHkgY29ubmVjdGVkIHdpdGgg U2VHVyB3aXRob3V0IFJFRElSRUNUIHN1cHBvcnTigJ3igJ0NCg0KUmVxdWVzdCBmb3IgY29tbWVu dHM6IC0NClBsZWFzZSByZWFkIHRoZSBwcm9ibGVtLCBpbXBhY3QgYW5kIHNvbHV0aW9uIGxpc3Rl ZCBhYm92ZSBhbmQgbGV0IG1lIGtub3cgaWYgYW55IGNvbW1lbnRzLiBIb3BlIG15IHBvaW50IGlz IHZhbGlkIGFuZCBuZWVkcyB0byBiZSBpbmNvcnBvcmF0ZWQgYXMgdGhlIFJGQyB1cGRhdGUuDQoN Cg0KUmVnYXJkcywNClZpamF5IE4uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpJUHNlYyBtYWlsaW5nIGxpc3QNCklQc2VjQGlldGYub3JnPG1haWx0 bzpJUHNlY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXBzZWMNCg== --_000_AD5AD8B0B070044BAD3C37D7057F37E153FE64F9szxeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBo LCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2lu LXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJn aW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNDA0MjU2NDc2Ow0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNzc1MjM2NzEyIDY3Njk4NzA1IDY3Njk4 NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEz IDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXRh Yi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt dGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCm9sDQoJ e21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+SGkgQWhtYWQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPklmIHlvdSBtZWFudCByZS1u ZWdvdGlhdGluZyBpcyBJS0V2MiByZWtleSB0aGVuIGl0IHdpbGwgbm90IHdvcmsgYmVjYXVzZSBJ S0V2MiByZWtleSB3aWxsIG5vdCBzZW5kIGFueSBJS0VfU0FfSU5JVCBwYWNrZXQuIEFzIG9mIG5v dywgdGhlIFJGQyBzYXlzIHRoYXQgUkVESVJFQ1RfU1VQUE9SVEVEIHBheWxvYWQgY2FuIGJlIHNl bnQgb25seSBpbiBJS0VfU0FfSU5JVA0KIG1zZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+T1I8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+SWYgeW91IG1lYW50IHJlLW5lZ290aWF0aW5nIGlzIGNvbXBsZXRlbHkgZGVsZXRlIHRo ZSBjdXJyZW50IFNBIGFuZCByZS1uZWdvdGlhdGUgdGhlIFNBIGZyb20gc2NyYXRjaCwgdGhpcyB3 b3VsZCBsZWFkIHRvIHNlcnZpY2UgbG9zcy9wa3QgbG9zcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPlJlY29tbWVuZGF0aW9uOiAtPG86cD48L286cD48L3NwYW4+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5T aW5jZSB0PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5oZSBiYXNlIHN0YXRpb25z IG5vcm1hbGx5IGVzdGFibGlzaCBUdW5uZWwgd2l0aCBvdGhlciB2ZW5kb3IgYmFzZSBzdGF0aW9u cyBhbmQvb3Igb3RoZXIgdmVuZG9yIEdhdGV3YXlzIHdoaWNoIG1heSBvciBtYXkgbm90IHN1cHBv cnQgJm5ic3A7UkVESVJFQ1QsIGl0IGlzIGJldHRlciB0byBhZGQgdGhpcw0KIHNvbHV0aW9uIChj bGllbnQgdG8gc2VuZCBhIG5ldyBJTkZPIG1zZyB3aXRoIHRoZSBSRURJUkVDVF9TVVBQT1JURUQg bm90aWZ5IHBheWxvYWQpIHRvIGVuYWJsZSBhIFNNT09USCBpbnRlci1vcCB3aXRoIG90aGVyIHZl bmRvciBpbXBsZW1lbnRhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5CZWNhdXNlIG9mIHRoZXNlIHJlYXNvbnMsIEkgZmVlbCB0aGUgUkZDIG5lZWRzIGNvcnJlY3Rp b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFobWFkIE11aGFubmEgW21haWx0bzphc211 aGFubmFAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgTWF5IDA0LCAyMDE0 IDk6NDEgUE08YnI+DQo8Yj5Ubzo8L2I+IHZpamF5IGtuPGJyPg0KPGI+Q2M6PC9iPiB2aWpheUB3 aWNob3J1cy5jb207IGtpbGlhbi53ZW5pZ2VyQGdvb2dsZW1haWwuY29tOyBpcHNlY0BpZXRmLm9y ZzsgdmprdW1hcjIwMDNAZ21haWwuY29tPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSVBzZWNd IFJlZ2FyZGluZyBJS0V2MiBSRURJUkVDVCBwcm9ibGVtIChyZWZlcmVuY2UgUkZDIDU2ODUpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCBW aWpheSwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBhbSBOT1Qgb25lIGlmIHRoZSBhdXRob3JzIG9mIHRoaXMgUkZDIGJ1dCBJIHJl Y2FsbCB0aGUgZGlzY3Vzc2lvbiBhbmQgdGhlIHVzZSBjYXNlLiBJZiBJIHVuZGVyc3RhbmQgdGhl IHNjZW5hcmlvIGNvcnJlY3RseSwgdGhlIGNsaWVudCBpbiB0aGlzIGNhc2UgKGVOQikgbmVnb3Rp YXRlZCBhbiBJS0UgU0Egd2l0aG91dCBpbmRpY2F0aW5nIHRoZSBhYmlsaXR5IHRvIHN1cHBvcnQg UkVESVJFQ1QuIElmIHRoYXQNCiBpcyB0aGUgY2FzZSwgdGhlIGNsaWVudCBzaG91bGQgcmVuZWdv dGlhdGUgSUtFIFNBIGFmdGVyIGJlaW5nIHVwZ3JhZGVkIHRvIHN1cHBvcnQgdGhpcyBmdW5jdGlv bmFsaXR5LiBNeSB1bmRlcnN0YW5kaW5nIHJlbmVnb3RpYXRpbmcgSUtFIFNBIGlzIHN1cHBvcnRl ZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SU1PLCBJIGRvIG5vdCB0aGluayB0aGF0IGFueXRoaW5nIGluIHRoaXMgUkZDIG5lZWRzIHRvIGJl IGNoYW5nZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQpSZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFobWFkIE11aGFubmEmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48YnI+DQpPbiBNYXkgMiwgMjAxNCwgYXQgOToxNCBBTSwgdmlqYXkga24gJmx0OzxhIGhyZWY9 Im1haWx0bzp2aWpheS5rbkBodWF3ZWkuY29tIj52aWpheS5rbkBodWF3ZWkuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgaXMgYW4g aXNzdWUgaW4gPHNwYW4gc3R5bGU9ImNvbG9yOiNDMDUwNEQiPklLRXYyIFJFRElSRUNUIFJGQyA1 Njg1PC9zcGFuPi4gSW4gb25lIHNjZW5hcmlvLCB0aGUgSUtFdjIgUkVESVJFQ1Qgd2lsbCBub3Qg d29yayBpbmRlZmluaXRlbHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPlNjZW5hcmlvOiAt PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGV04oCZcyBhc3N1bWUg dGhlcmUgYXJlIGFib3V0IDEwMDAgY2xpZW50cyBjb25uZWN0ZWQgdG8gYSBJS0V2MiBSRURJUkVD VCBlbmFibGVkIFNlR1cuDQo8Yj5Ob25lIG9mIHRoZSBjbGllbnRzIHdlcmUgSUtFdjIgcmVkaXJl Y3QgZW5hYmxlZCBhdCB0aGUgdGltZSBvZiBlc3RhYmxpc2hpbmcgU0E8L2I+IHdpdGggdGhlIFNl R1cgKG1lYW5pbmcgdGhleSBoYXZlIG5vdCBzZW50IHRoZSBSRURJUkVDVF9TVVBQT1JURUQgbm90 aWZpY2F0aW9uIGluIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SUtF X1NBX0lOSVQgbWVzc2FnZSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo aXMgd2lsbCBsZWFkIHRvIGEgc2l0dWF0aW9uIHdoZXJlIHRoZSBTZUdXIGlzIGxvYWRlZCBhbmQg d2FudGluZyB0byByZWRpcmVjdCBzb21lIGNsaWVudHMgdG8gYW5vdGhlciBTZUdXIGJ1dCBpdCBj YW5ub3QgUkVESVJFQ1QgdGhlbSBhcyBub25lIG9mIHRoZW0gaGF2ZSBpbmRpY2F0ZWQgUkVESVJF Q1Qgc3VwcG9ydCBpbiB0aGUgSUtFX1NBX0lOSVQgbWVzc2FnZS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSB1c2VyL29wZXJhdG9yIGVuYWJsZWQgUkVESVJFQ1Qg ZnVuY3Rpb25hbGl0eSBkeW5hbWljYWxseSAobGlrZSBhZnRlciBTQXMgd2VyZSBlc3RhYmxpc2hl ZCksIHRoZW4gdGhlIFNlR1cgaXMgbm90IGdvaW5nIHRvIHJlZGlyZWN0IHRoZW0gYmVjYXVzZSBp dCBoYWQgbm90IHJlY2VpdmVkIGEgUkVESVJFQ1RfU1VQUE9SVEVEIHBheWxvYWQgZnJvbSB0aGUg Y2xpZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RWZmZWN0L0ltcGFjdDogLTwvYj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgbGVhZHMgdG8gYSBjb25n ZXN0aW9uL292ZXJsb2FkIGF0IHRoZSBnYXRld2F5IHdoZW4gdGhlIGJhc2Ugc3RhdGlvbnMgY29u bmVjdGluZyB0byB0aGUgU2VHVyBhcmUgc2V2ZXJhbCBodW5kcmVkL3Rob3VzYW5kcyBpbiBudW1i ZXIuIEluIHRoZSBMVEUgYW5kIExURS1BIHNjZW5hcmlvcywgdGhpcyBjb25kaXRpb24gaXMgcG9z c2libGUgd2hlcmUgdGhlIG51bWJlciBvZiBiYXNlIHN0YXRpb25zIGNvbm5lY3RpbmcNCiB0byB0 aGUgU2VHVyBhcmUgdmVyeSBoaWdoLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5TdWdnZXN0 aW9uL1NvbHV0aW9uOiAtPC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QSBjaGFuZ2UgaXMgcmVxdWlyZWQgaW4gUkZDIDU2ODUgaXMgcmVxdWlyZWQgYXMgYmVsb3c6IC08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj QzA1MDREIj7igJzigJ1XaGVuZXZlciB0aGUgcmVkaXJlY3QgZmVhdHVyZS9mdW5jdGlvbmFsaXR5 IGlzIGVuYWJsZWQgYXQgcnVuLXRpbWUsIHRoZSBjbGllbnQgc2hvdWxkIGluZGljYXRlIHRoZSBz YW1lIHRvIHRoZSBTZUdXLiBUaGlzIGNhbiBiZSBkb25lIGJ5IHRoZSBjbGllbnQgc2VuZGluZyBh biBJTkZPUk1BVElPTkFMIG1lc3NhZ2UgJm5ic3A7dW5kZXIgdGhlIHByb3RlY3Rpb24gb2YNCiB0 aGUgSUtFIFNBLiBUaGlzIG1lc3NhZ2UgTVVTVCBoYXZlIGEgUkVESVJFQ1RfU1VQUE9SVEVEIG5v dGlmeSBwYXlsb2FkIHRvIGVuYWJsZSB0aGUgU2VHVyB0byByZWRpcmVjdCB0aGVtIGF0IHJ1bi10 aW1lIGV2ZW4gdGhvdWdoIHRoZXkgaGFkIGluaXRpYWxseSBjb25uZWN0ZWQgd2l0aCBTZUdXIHdp dGhvdXQgUkVESVJFQ1Qgc3VwcG9ydOKAneKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+UmVxdWVzdCBmb3IgY29tbWVudHM6IC08L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5QbGVhc2UgcmVhZCB0aGUgcHJvYmxlbSwgaW1wYWN0IGFuZCBzb2x1dGlv biBsaXN0ZWQgYWJvdmUgYW5kIGxldCBtZSBrbm93IGlmIGFueSBjb21tZW50cy4gSG9wZSBteSBw b2ludCBpcyB2YWxpZCBhbmQgbmVlZHMgdG8gYmUgaW5jb3Jwb3JhdGVkIGFzIHRoZSBSRkMgdXBk YXRlLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlZpamF5IE4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklQc2VjIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJUHNlY0BpZXRmLm9yZyI+SVBzZWNAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p cHNlYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYzwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_AD5AD8B0B070044BAD3C37D7057F37E153FE64F9szxeml513mbxchi_-- From nobody Sun May 4 23:09:06 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAD21A025B for ; Sun, 4 May 2014 23:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ud-z4c95se54 for ; Sun, 4 May 2014 23:07:26 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3461A025A for ; Sun, 4 May 2014 23:07:25 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id e16so186294lan.33 for ; Sun, 04 May 2014 23:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type; bh=qCrH3+WDhA++izR13GaO3xlNjpHHiOPW9XltVlJTNVA=; b=QeGgULBLvJV2DfIkY563LfsgXPcNXQ1qx72DDtIyhqFIJuf3KheqX4TnR0uumm0/wZ HXRrzMei7ZR71mf+4x1M9ZSGOh+IJJT8baYkdwQ9pl4z0lCWk3ywzBg4PwFddpszJPnz ISJqgdN7DIDG95l0ejjQdwpmht9DCIlRy39flEWKuC9v79GHdhOKFEHPlmZGyBzZ5ZRy i89r9zwEX/NSG16Ldx9bS9ynzcNkQ701cFimWtDQPHVd8MPkwERSD/TN3mRlnlJhxN6W yL8WYHYTSFxOqrgn1bDlMulNvvVBBph4WkMrxXHyR21fLEXPvnfwv5uoZhVoExccTP7J o3Ug== X-Received: by 10.152.42.196 with SMTP id q4mr10920067lal.14.1399270042046; Sun, 04 May 2014 23:07:22 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id a7sm8454430lbc.9.2014.05.04.23.07.20 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 04 May 2014 23:07:21 -0700 (PDT) Message-ID: <547BC776F83D4706A2319725512A3314@buildpc> From: "Valery Smyslov" To: "vijay kn" , "Yoav Nir" References: <22DBA0CE-BF37-48E2-A87D-B1D66E64DE1B@gmail.com> Date: Mon, 5 May 2014 10:07:19 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003E_01CF6849.CCC57E30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/_ePmM3wuCXQNpFZ7blJIgMdZiYg Cc: ipsec@ietf.org, vijay@wichorus.com, kilian.weniger@googlemail.com, vjkumar2003@gmail.com Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 06:07:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_003E_01CF6849.CCC57E30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Vijay, ----- Original Message -----=20 From: vijay kn=20 To: Yoav Nir=20 Cc: ipsec@ietf.org ; vijay@wichorus.com ; = kilian.weniger@googlemail.com ; vjkumar2003@gmail.com=20 Sent: Monday, May 05, 2014 8:08 AM Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC = 5685) Hi Yoav, Yes your understanding is right. They are disabled by configuration = but later enabled may be after tunnel is setup. FYI, it has no relation with roaming. =20 I can see this as a case like:=20 1) When a base station is initially not REDIRECT enabled but = later the software version is upgraded to the version that has REDIRECT = support If you upgrade software, you will need to reestablish all IKE SAs in any = case. 2) The base station normally will be REDIRECT disabled because = the base station might establish Tunnel with other base stations and/or = other SeGWs which may or may not support REDIRECT. So the config will = be disabled by default. Sorry, I don't see the reason to have REDIRECT disabled by default if = you support it. You may safely always offer=20 support for it. If peer is SecGW and also supports it, you will have it = negotiated and then it may be used it in any time. Otherwise peer will just not return REDIRECT_SUPPORTED = notification and you will live without it. The only reason to have REDIRECT disabled that I can = imagine of is situation, when your peer's implementation is broken and doesn't ignore unknown = status notification, but instead, for example, crashes . I don't think this reason justifies = changing RFC. Note, that RFC5723 is not the only IKE extension RFC that have feature = support negotiation during establishing of IKE SA. The same is true for RFC4555 (MOBIKE) and = RFC6311 (support for HA). This is common practice for IKE extensions to be negotiated during IKE = SA establishment. Regards, Valery Smyslov. Thanks. =20 From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Sunday, May 04, 2014 12:56 PM To: vijay kn Cc: ipsec@ietf.org; vijay@wichorus.com; kilian.weniger@googlemail.com; = vjkumar2003@gmail.com Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC = 5685) =20 Hi Vijay =20 I'm no expert on REDIRECT, and my implementation does not support it.=20 =20 Your issue seems to be about implementations that have the REDIRECT = functionality, but don't advertise as much when they connect to the peer = gateway. So it's as if this feature is disabled by configuration. Am I = understanding this correctly? =20 =20 So my question to you would be why this would make sense. Why do these = clients enable and disable the feature during the lifetime on an IKEv2 = SA? Why not leave is always on? =20 Is this some kind of roaming issue? =20 Yoav =20 On May 2, 2014, at 5:14 PM, vijay kn wrote: Hi, There is an issue in IKEv2 REDIRECT RFC 5685. In one scenario, the = IKEv2 REDIRECT will not work indefinitely. =20 Scenario: - Let's assume there are about 1000 clients connected to a IKEv2 = REDIRECT enabled SeGW. None of the clients were IKEv2 redirect enabled = at the time of establishing SA with the SeGW (meaning they have not sent = the REDIRECT_SUPPORTED notification in the IKE_SA_INIT message) This will lead to a situation where the SeGW is loaded and wanting to = redirect some clients to another SeGW but it cannot REDIRECT them as = none of them have indicated REDIRECT support in the IKE_SA_INIT message. If the user/operator enabled REDIRECT functionality dynamically (like = after SAs were established), then the SeGW is not going to redirect them = because it had not received a REDIRECT_SUPPORTED payload from the = clients. =20 Effect/Impact: - This leads to a congestion/overload at the gateway when the base = stations connecting to the SeGW are several hundred/thousands in number. = In the LTE and LTE-A scenarios, this condition is possible where the = number of base stations connecting to the SeGW are very high. =20 Suggestion/Solution: - A change is required in RFC 5685 is required as below: - ""Whenever the redirect feature/functionality is enabled at run-time, = the client should indicate the same to the SeGW. This can be done by the = client sending an INFORMATIONAL message under the protection of the IKE = SA. This message MUST have a REDIRECT_SUPPORTED notify payload to enable = the SeGW to redirect them at run-time even though they had initially = connected with SeGW without REDIRECT support"" =20 Request for comments: - Please read the problem, impact and solution listed above and let me = know if any comments. Hope my point is valid and needs to be = incorporated as the RFC update. =20 =20 Regards, Vijay N. =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 -------------------------------------------------------------------------= ----- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_003E_01CF6849.CCC57E30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Vijay,
 
----- Original Message -----
From:=20 vijay kn=20
Cc: ipsec@ietf.org ; vijay@wichorus.com ; kilian.weniger@googlemail.c= om=20 ; vjkumar2003@gmail.com
Sent: Monday, May 05, 2014 8:08 = AM
Subject: Re: [IPsec] Regarding = IKEv2=20 REDIRECT problem (reference RFC 5685)

Hi=20 Yoav,

Yes=20 your understanding is right. They are disabled by configuration but = later=20 enabled may be after tunnel is setup.

FYI,=20 it has no relation with roaming.

 

I=20 can see this as a case like:

1)     =20 When=20 a base station is initially not REDIRECT enabled but later the = software=20 version is upgraded to the version that has REDIRECT=20 support

If=20 you upgrade software, you will need to reestablish all IKE SAs in any=20 case.

2)     =20 The=20 base station normally will be REDIRECT disabled because the base = station might=20 establish Tunnel with other base stations and/or other SeGWs which may = or may=20 not support  REDIRECT. So the config will be disabled by=20 default.

Sorry,=20 I don't see the reason to have REDIRECT disabled by default if you = support it.=20 You may safely always offer

support=20 for it. If peer is SecGW and also supports it, you will have it = negotiated=20 and then it may be  used

it=20 in any time. Otherwise peer will just not return REDIRECT_SUPPORTED = notification=20 and you will

live=20 without it. The only reason to have REDIRECT disabled that I can imagine = of is=20 situation,

when=20 your peer's implementation is broken and doesn't ignore unknown = status=20 notification,

but=20 instead, for example, crashes . I don't think this reason justifies = changing=20 RFC.

 

Note,=20 that RFC5723 is not the only IKE extension RFC that have feature support = negotiation

during=20 establishing of IKE SA. The same is true for RFC4555 (MOBIKE) = and RFC6311=20 (support for HA).

This=20 is common practice for IKE extensions to be negotiated during IKE SA=20 establishment.

 

Regards,

Valery=20 Smyslov.

 

 Thanks.

 

From: IPsec=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav = Nir
Sent:=20 Sunday, May 04, 2014 12:56 PM
To: vijay kn
Cc:=20 ipsec@ietf.org; vijay@wichorus.com; kilian.weniger@googlemail.com;=20 vjkumar2003@gmail.com
Subject: Re: [IPsec] Regarding IKEv2 = REDIRECT=20 problem (reference RFC 5685)

 

Hi Vijay

 

I=92m no expert on REDIRECT, and my = implementation does not=20 support it. 

 

Your issue seems to be about implementations that = have the=20 REDIRECT functionality, but don=92t advertise as much when they = connect to the=20 peer gateway. So it=92s as if this feature is disabled by = configuration. Am I=20 understanding this correctly?  

 

So my question to you would be why this would = make sense.=20 Why do these clients enable and disable the feature during the = lifetime on an=20 IKEv2 SA? Why not leave is always on?

 

Is this some kind of roaming = issue?

 

Yoav

 

On May 2, 2014, at 5:14 PM, vijay kn <vijay.kn@huawei.com>=20 wrote:



Hi,

There = is an issue=20 in IKEv2 REDIRECT RFC 5685. In one = scenario, the=20 IKEv2 REDIRECT will not work indefinitely.

 

Scenario:=20 -

Let=92s = assume=20 there are about 1000 clients connected to a IKEv2 REDIRECT enabled = SeGW. None of the clients were = IKEv2=20 redirect enabled at the time of establishing SA with the SeGW (meaning they = have not=20 sent the REDIRECT_SUPPORTED notification in = the

IKE_SA_INIT=20 message)

This = will lead to=20 a situation where the SeGW is loaded and wanting to redirect some = clients to=20 another SeGW but it cannot REDIRECT them as none of them have = indicated=20 REDIRECT support in the IKE_SA_INIT = message.

If the=20 user/operator enabled REDIRECT functionality dynamically (like after = SAs were=20 established), then the SeGW is not going to redirect them because it = had not=20 received a REDIRECT_SUPPORTED payload from the=20 clients.

 

Effect/Impact:=20 -

This = leads to a=20 congestion/overload at the gateway when the base stations connecting = to the=20 SeGW are several hundred/thousands in number. In the LTE and LTE-A = scenarios,=20 this condition is possible where the number of base stations = connecting to the=20 SeGW are very high.

 

Suggestion/Solution:=20 -

A = change is=20 required in RFC 5685 is required as below: = -

=93=94Whenever=20 the redirect feature/functionality is enabled at run-time, the client = should=20 indicate the same to the SeGW. This can be done by the client sending = an=20 INFORMATIONAL message  under the protection of the IKE SA. This = message=20 MUST have a REDIRECT_SUPPORTED notify payload to enable the SeGW to = redirect=20 them at run-time even though they had initially connected with SeGW = without=20 REDIRECT support=94=94

 

Request = for=20 comments: -

Please = read the=20 problem, impact and solution listed above and let me know if any = comments.=20 Hope my point is valid and needs to be incorporated as the RFC=20 update.

 

 

Regards,

Vijay=20 N.

 

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

 

_______________________________________________
IPsec = mailing=20 = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
= ------=_NextPart_000_003E_01CF6849.CCC57E30-- From nobody Sun May 4 23:35:30 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA561A0260 for ; Sun, 4 May 2014 23:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.889 X-Spam-Level: X-Spam-Status: No, score=0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIf0I8X87BUr for ; Sun, 4 May 2014 23:35:26 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id 616211A0164 for ; Sun, 4 May 2014 23:35:26 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id z11so5006540lbi.12 for ; Sun, 04 May 2014 23:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=0ytMZzWCqkB+3ri3UoOGLDCVlB0iMJlyDiwICDnfwFc=; b=YUt9oYxKdG5c4vgnqT3rU0V2uplrJqA2R6rEdkDwXgqc1UatpiFCUQRRJWx/vWiy83 c6Z1OXtkfVz+e/H7A5AQVK10jTdPqqnZL+Vos+MhB5PS/a35RtN90MFjGrXNSk7kzcF/ zDzmqRTMeZB4+ZqZ0/nGIHysiwsWY2L8t5U6rNK1RHu5krKPcedhXg43pvswBNmQaYGR pqUsBA5Ugh7evc1T45NAUJMyVyvWZU7vG1EBiD2FNEvJKpGOcxGTidTOQFDOABP8fm5s a9BWkaI4WHeTfJ+Hlj5726cJWxnZO4aRaHFl47K5ps77CqcZjyf2oqObKAULlkntTXYr j6wA== X-Received: by 10.112.142.68 with SMTP id ru4mr289912lbb.49.1399271722418; Sun, 04 May 2014 23:35:22 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id r9sm1019329lal.0.2014.05.04.23.35.20 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 04 May 2014 23:35:20 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Syed Ajim Hussain" , "Yoav Nir" References: <335B84BDA2818C428E63D9B0ADE6863545AF7228@szxeml561-mbx.china.huawei.com> <335B84BDA2818C428E63D9B0ADE6863545AF7A1A@szxeml561-mbx.china.huawei.com> Date: Mon, 5 May 2014 10:35:19 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/1LPRSS9kpk1En2bp-J-nYL8LdgA Cc: ipsec@ietf.org Subject: Re: [IPsec] Simultaneous Child SA Creation tigger from both theside. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 06:35:28 -0000 Hi Syed Ajim, > Hi Yoav > Thanks for your reply, This problem happened in real scenario, > problem is- both the Tunnel end points are different vendor, > They handle it differently. > > We can defined this behavior in RFC, > > Also we have some other scenarios, it will be better if we define > these extreme case behavior also in RFC, > to make inter-op smooth. I agree with Yoav that this situation is extremely rare in practice. Note, that RFC4301 deliberately allows to have multiple IPsec SAs established betwen the same peers with the same traffic selectors (for example for the purposes of QoS). So, you can't just delete "erroneous" SA because you have SA with the same traffic selector - the peer may create it for purpose. What about your use case - what's wrong if there are two SAs? Of course, it is some waste of resources, but if your implementation selects outgoing SA deterministically and both peers use the same SA, the other will eventually die by lifetime expiration (as no traffic will flow through it). Regards, Valery Smyslov. > With Regards > Syed Ajim > > -----Original Message----- > From: Yoav Nir [mailto:ynir.ietf@gmail.com] > Sent: 2014Äê5ÔÂ4ÈÕ 12:49 > To: Syed Ajim Hussain > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Simultaneous Child SA Creation tigger from both the > side. > > Hi > > The reason that we don¡¯t have any mention of simultaneous SA creation is > that this issue has not come up in practice. When two IPsec hosts don¡¯t > have an SA for a particular flow (because said flow hasn¡¯t had traffic in > a while), it¡¯s highly unlikely that bidirectional traffic on this flow > will begin simultaneously, or at least before the 1-2 roundtrips it takes > to set up a child SA. > > On the other hand, when SA lifetimes are set and traffic is continuous, it¡¯s very likely that two such implementations will begin a rekeying at the > same time. > > So what would happen? Both implementations get a CreateChildSA request > (or an IKE_AUTH request) after each has sent out its own request. I guess > we could specify it the same way as in section 2.8.1, but doing this would > be a problem because this is not specified and other implementations are > likely not to do it. > > Sorry I don¡¯t have a better answer for you. > > Yoav > > On May 2, 2014, at 3:27 PM, Syed Ajim Hussain wrote: > >> Hi All. >> >> Host A --------------Host B >> >> Assume Host-A & Host-B want to established IPSEC Tunnel, First they >> established one IKE SA and one IPSEC SA (Child SA). >> >> After that due to addition of a new IPSEC Policy(SPD), Both the sides >> triggered one more Child SA creation. >> >> This Child SA creation hit simultaneous Child SA Creation condition. >> Since both the side triggered for Child SA >> Creation for one Configured SPD (Traffic Flow). >> >> In RFC 5996 , there is no point mention about simultaneous exchange >> during Child SA create, it only mention Simultaneous >> Handling during Child SA Rekey. >> >> What should be the behavior in case of Simultaneous Child SA >> Creation, if implementation maintain one Child SA per one Traffic Flow >> (SPD). >> >> Does Simultaneous Child SA Rekeying - method also applicable in case >> of Child SA Creation (not Rekey). >> >> >> 2.8.1. Simultaneous Child SA Rekeying >> >> If the two ends have the same lifetime policies, it is possible that >> both will initiate a rekeying at the same time (which will result in >> redundant SAs). To reduce the probability of this happening, the >> timing of rekeying requests SHOULD be jittered (delayed by a random >> amount of time after the need for rekeying is noticed). >> >> >> >> >> Kaufman, et al. Standards Track [Page 36] >> >> RFC 5996 IKEv2bis September 2010 >> >> >> This form of rekeying may temporarily result in multiple similar SAs >> between the same pairs of nodes. When there are two SAs eligible to >> receive packets, a node MUST accept incoming packets through either >> SA. If redundant SAs are created though such a collision, the SA >> created with the lowest of the four nonces used in the two exchanges >> SHOULD be closed by the endpoint that created it. "Lowest" means an >> octet-by-octet comparison (instead of, for instance, comparing the >> nonces as large integers). In other words, start by comparing the >> first octet; if they're equal, move to the next octet, and so on. If >> you reach the end of one nonce, that nonce is the lower one. The >> node that initiated the surviving rekeyed SA should delete the >> replaced SA after the new one is established. >> >> The following is an explanation on the impact this has on >> implementations. Assume that hosts A and B have an existing Child SA >> pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same >> time: >> >> Host A Host B >> ------------------------------------------------------------------- >> send req1: N(REKEY_SA,SPIa1), >> SA(..,SPIa2,..),Ni1,.. --> >> <-- send req2: N(REKEY_SA,SPIb1), >> SA(..,SPIb2,..),Ni2 >> recv req2 <-- >> >> At this point, A knows there is a simultaneous rekeying happening. >> However, it cannot yet know which of the exchanges will have the >> lowest nonce, so it will just note the situation and respond as >> usual. >> >> send resp2: SA(..,SPIa3,..), >> Nr1,.. --> >> --> recv req1 >> >> Now B also knows that simultaneous rekeying is going on. It responds >> as usual. >> >> <-- send resp1: SA(..,SPIb3,..), >> Nr2,.. >> recv resp1 <-- >> --> recv resp2 >> >> At this point, there are three Child SA pairs between A and B (the >> old one and two new ones). A and B can now compare the nonces. >> Suppose that the lowest nonce was Nr1 in message resp2; in this case, >> B (the sender of req2) deletes the redundant new SA, and A (the node >> that initiated the surviving rekeyed SA), deletes the old one. >> >> >> >> Kaufman, et al. Standards Track [Page 37] >> >> RFC 5996 IKEv2bis September 2010 >> >> >> send req3: D(SPIa1) --> >> <-- send req4: D(SPIb2) >> --> recv req3 >> <-- send resp3: D(SPIb1) >> recv req4 <-- >> send resp4: D(SPIa3) --> >> >> The rekeying is now finished. >> >> However, there is a second possible sequence of events that can >> happen if some packets are lost in the network, resulting in >> retransmissions. The rekeying begins as usual, but A's first packet >> (req1) is lost. >> >> Host A Host B >> ------------------------------------------------------------------- >> send req1: N(REKEY_SA,SPIa1), >> SA(..,SPIa2,..), >> Ni1,.. --> (lost) >> <-- send req2: N(REKEY_SA,SPIb1), >> SA(..,SPIb2,..),Ni2 >> recv req2 <-- >> send resp2: SA(..,SPIa3,..), >> Nr1,.. --> >> --> recv resp2 >> <-- send req3: D(SPIb1) >> recv req3 <-- >> send resp3: D(SPIa1) --> >> --> recv resp3 >> >> From B's point of view, the rekeying is now completed, and since it >> has not yet received A's req1, it does not even know that there was >> simultaneous rekeying. However, A will continue retransmitting the >> message, and eventually it will reach B. >> >> resend req1 --> >> --> recv req1 >> >> To B, it looks like A is trying to rekey an SA that no longer exists; >> thus, B responds to the request with something non-fatal such as >> CHILD_SA_NOT_FOUND. >> >> <-- send resp1: N(CHILD_SA_NOT_FOUND) >> recv resp1 <-- >> >> When A receives this error, it already knows there was simultaneous >> rekeying, so it can ignore the error message >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Mon May 5 05:45:12 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C309F1A0079 for ; Mon, 5 May 2014 05:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdze3ea48VaG for ; Mon, 5 May 2014 05:45:06 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 71D801A015E for ; Mon, 5 May 2014 05:45:06 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id z60so2295545qgd.9 for ; Mon, 05 May 2014 05:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d1yjd9Vm8JNLlMfjas+nNcPQcJGffHfFUpGF88kAJyo=; b=s3OIYoFL3XiLcPvuTQ1BiSRTzsVErNyI4/tcuLmdcb0sDySbZo9IQmqT6BTOsATqg+ RR8tjz0Bxqt54nWf4j0RbbCXU8cmUPzngk4RBfrZoG9BqyOXQh5RANUjSRplcIuENKEU 8ZIjuH2PyAFqBu057BJfaUYSf6z34Q//mEwcpo/SUoDt1muOwcmZ1U19NK0f6MEnBBNw 1C81ln1oWOu7nkT3QThoPzKZ9LI7gDgCSRpx6k1Ob8OB96GOIUH3EDweaEsTPYF/75Uu fEG57r8kIhxv6DahAH1X912R+1WpiJ+sbQFv01vWyHqTcyUSYUAqG1w0irm55TQFQ/Wt R/fg== MIME-Version: 1.0 X-Received: by 10.140.102.166 with SMTP id w35mr41485525qge.97.1399293902816; Mon, 05 May 2014 05:45:02 -0700 (PDT) Received: by 10.140.84.7 with HTTP; Mon, 5 May 2014 05:45:02 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 May 2014 07:45:02 -0500 Message-ID: From: Ahmad Muhanna To: vijay kn Content-Type: multipart/alternative; boundary=001a11c15f3a03934304f8a68014 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/eSwpp9rWEu8UPQasOX8bD3IkZu4 Cc: "ipsec@ietf.org" , "kilian.weniger@googlemail.com" , "vjkumar2003@gmail.com" Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 12:45:10 -0000 --001a11c15f3a03934304f8a68014 Content-Type: text/plain; charset=ISO-8859-1 Hi Vijay, Please see comments inline. On Mon, May 5, 2014 at 12:30 AM, vijay kn wrote: > Hi Ahmad, > > If you meant re-negotiating is IKEv2 rekey then it will not work because > IKEv2 rekey will not send any IKE_SA_INIT packet. As of now, the RFC says > that REDIRECT_SUPPORTED payload can be sent only in IKE_SA_INIT msg. > > OR > > If you meant re-negotiating is completely delete the current SA and > re-negotiate the SA from scratch, this would lead to service loss/pkt loss. > > > [Ahmad] Yes. I meant the later. If we look at all scenarios that could be applicable to what you are trying to solve, one end of the IKE SA needs to be upgraded to support REDIRECTION. In my experience, that always happens in a controlled environment (i.e., a maintenance window). In addition, operators do this kind of activity very carefully and NOT globally; meaning, they upgrade a limited number of nodes at a time or during a specific period. The fact that the client and the SeGW -OR- the peers are from different vendors or even in different operator domains for the sake of making this more complex, it is always the case that when a new functionality is introduced, there is an expectation of service interruption. NOW: even if we allow this feature as part of this RFC, there is still no guarantee for the functionality to be successfully negotiated using the proposed solution. Because that will introduce another level of complexity and other backward compatibility scenarios that need to be considered when one of the peers support this functionality and the other does not. For example: what about if the SeGW support REDIRECTION as per RFC5685 but NOT by the newly introduced functionality (assuming that has been adopted). Although, the SeGW support REDIRECTION, but it would NOT be able to recognize and support this functionality. This means that it wont work but renegotiation of the IKE SA will still work. IMO, what you are trying to do is a completely new feature that is not in the scope of this RFC and that is why I said this RFC does not need to be updated or changed. I believe what you are trying to do is some kind of dynamic mechanism that allow one peer to check with the other peer on what kind of functionality it supports vs. what it does NOT support with some forward compatibility in mind. That is totally and completely different than this RFC and can be applicable to many other scenarios and RFCs other than this one. I hope I am making sense. Regards, Ahmad > *Recommendation: -* > > Since the base stations normally establish Tunnel with other vendor base > stations and/or other vendor Gateways which may or may not support > REDIRECT, it is better to add this solution (client to send a new INFO msg > with the REDIRECT_SUPPORTED notify payload) to enable a SMOOTH inter-op > with other vendor implementations. > > > > Because of these reasons, I feel the RFC needs correction. > > > > > > *From:* Ahmad Muhanna [mailto:asmuhanna@gmail.com] > *Sent:* Sunday, May 04, 2014 9:41 PM > *To:* vijay kn > *Cc:* vijay@wichorus.com; kilian.weniger@googlemail.com; ipsec@ietf.org; > vjkumar2003@gmail.com > *Subject:* Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC > 5685) > > > > Hi, Vijay, > > > > I am NOT one if the authors of this RFC but I recall the discussion and > the use case. If I understand the scenario correctly, the client in this > case (eNB) negotiated an IKE SA without indicating the ability to support > REDIRECT. If that is the case, the client should renegotiate IKE SA after > being upgraded to support this functionality. My understanding > renegotiating IKE SA is supported. > > > > IMO, I do not think that anything in this RFC needs to be changed. > > > Regards, > > Ahmad Muhanna > > > On May 2, 2014, at 9:14 AM, vijay kn wrote: > > Hi, > > There is an issue in IKEv2 REDIRECT RFC 5685. In one scenario, the IKEv2 > REDIRECT will not work indefinitely. > > > > *Scenario: -* > > Let's assume there are about 1000 clients connected to a IKEv2 REDIRECT > enabled SeGW. *None of the clients were IKEv2 redirect enabled at the > time of establishing SA* with the SeGW (meaning they have not sent the > REDIRECT_SUPPORTED notification in the > > IKE_SA_INIT message) > > This will lead to a situation where the SeGW is loaded and wanting to > redirect some clients to another SeGW but it cannot REDIRECT them as none > of them have indicated REDIRECT support in the IKE_SA_INIT message. > > If the user/operator enabled REDIRECT functionality dynamically (like > after SAs were established), then the SeGW is not going to redirect them > because it had not received a REDIRECT_SUPPORTED payload from the clients. > > > > *Effect/Impact: -* > > This leads to a congestion/overload at the gateway when the base stations > connecting to the SeGW are several hundred/thousands in number. In the LTE > and LTE-A scenarios, this condition is possible where the number of base > stations connecting to the SeGW are very high. > > > > *Suggestion/Solution: -* > > A change is required in RFC 5685 is required as below: - > > ""Whenever the redirect feature/functionality is enabled at run-time, the > client should indicate the same to the SeGW. This can be done by the client > sending an INFORMATIONAL message under the protection of the IKE SA. This > message MUST have a REDIRECT_SUPPORTED notify payload to enable the SeGW to > redirect them at run-time even though they had initially connected with > SeGW without REDIRECT support"" > > > > *Request for comments: -* > > Please read the problem, impact and solution listed above and let me know > if any comments. Hope my point is valid and needs to be incorporated as the > RFC update. > > > > > > Regards, > > Vijay N. > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > -- Regards, Ahmad --001a11c15f3a03934304f8a68014 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Vijay,

Please see comments inline.

On Mon, May 5, 2014 at 12:30 AM, vijay kn <vijay.kn@huawei.com> wrote:

Hi Ahmad,

If you meant re-negoti= ating is IKEv2 rekey then it will not work because IKEv2 rekey will not sen= d any IKE_SA_INIT packet. As of now, the RFC says that REDIRECT_SUPPORTED p= ayload can be sent only in IKE_SA_INIT msg.

OR

If you meant re-negoti= ating is completely delete the current SA and re-negotiate the SA from scra= tch, this would lead to service loss/pkt loss.

 

[Ahmad]
Yes. I meant the later.

If we look at all scenarios that could be applicabl= e to what you are trying to solve, one end of the IKE SA needs to be upgrad= ed to support REDIRECTION. In my experience, that always happens in a contr= olled environment (i.e., a maintenance window). In addition, operators do t= his kind of activity very carefully and NOT globally; meaning, they upgrade= a limited number of nodes at a time or during a specific period.

The fact that the client and the SeGW -OR- the peers ar= e from different vendors or even in different operator domains for the sake= of making this more complex, it is always the case that when a new functio= nality is introduced, there is an expectation of service interruption.

NOW: even if we allow this feature as part of this RFC,= there is still no guarantee for the functionality to be successfully negot= iated using the proposed solution. Because that will introduce another leve= l of complexity and other backward compatibility scenarios that need to be = considered when one of the peers support this functionality and the other d= oes not.

For example: what about if the SeGW support REDIRECTION= as per RFC5685 but NOT by the newly introduced functionality (assuming tha= t has been adopted). Although, the SeGW support REDIRECTION, but it would N= OT be able to recognize and support this functionality. This means that it = wont work but renegotiation of the IKE SA will still work.

IMO, what you are trying to do is a completely new feat= ure that is not in the scope of this RFC and that is why I said this RFC do= es not need to be updated or changed. I believe what you are trying to do i= s some kind of dynamic mechanism that allow one peer to check with the othe= r peer on what kind of functionality it supports vs. what it does NOT suppo= rt with some forward compatibility in mind.
That is totally and completely different than this RFC and can be appl= icable to many other scenarios and RFCs other than this one.

=
I hope I am making sense.

Regards,
Ahmad
  

<= span style=3D"color:#1f497d">

Recommendation: -

Since the base stations normally establish Tunnel with other= vendor base stations and/or other vendor Gateways which may or may not sup= port  REDIRECT, it is better to add this solution (client to send a new INFO msg with the REDIRECT_SUPPORTED notify= payload) to enable a SMOOTH inter-op with other vendor implementations.=

 

Because of these reaso= ns, I feel the RFC needs correction.

 

 

 

Hi, Vijay, 

 

I am NOT one if the authors of this RFC but I recall= the discussion and the use case. If I understand the scenario correctly, t= he client in this case (eNB) negotiated an IKE SA without indicating the ab= ility to support REDIRECT. If that is the case, the client should renegotiate IKE SA after being upgraded to = support this functionality. My understanding renegotiating IKE SA is suppor= ted.

 

IMO, I do not think that anything in this RFC needs = to be changed.


Regards,

Ahmad Muhanna 


On May 2, 2014, at 9:14 AM, vijay kn <vijay.kn@huawei.com> wrote:

Hi,

There is an issue in I= KEv2 REDIRECT RFC 5685. In one scenario, the IKEv2 REDIRECT will not= work indefinitely.

 

Scenario: -

Let’s assume there are about 1000 clients conn= ected to a IKEv2 REDIRECT enabled SeGW. None of the clients were IKEv2 redirect enabled at the time of establish= ing SA with the SeGW (meaning they have not sent the REDIRECT_SUPPORTED= notification in the

IKE_SA_INIT message)

This will lead to a situation where the SeGW is load= ed and wanting to redirect some clients to another SeGW but it cannot REDIR= ECT them as none of them have indicated REDIRECT support in the IKE_SA_INIT= message.

If the user/operator enabled REDIRECT functionality = dynamically (like after SAs were established), then the SeGW is not going t= o redirect them because it had not received a REDIRECT_SUPPORTED payload fr= om the clients.

 

Effect/Impact: -

This leads to a congestion/overload at the gateway w= hen the base stations connecting to the SeGW are several hundred/thousands = in number. In the LTE and LTE-A scenarios, this condition is possible where= the number of base stations connecting to the SeGW are very high.

 

Suggestion/Solution: -

A change is required in RFC 5685 is required as belo= w: -

“”Whenever= the redirect feature/functionality is enabled at run-time, the client shou= ld indicate the same to the SeGW. This can be done by the client sending an= INFORMATIONAL message  under the protection of the IKE SA. This message MUST have a REDIRECT_SUPPORTED notify payload to = enable the SeGW to redirect them at run-time even though they had initially= connected with SeGW without REDIRECT support””

 

Request for comments: -

Please read the problem, impact and solution listed = above and let me know if any comments. Hope my point is valid and needs to = be incorporated as the RFC update.

 

 

Regards,

Vijay N.

 

____________________________________= ___________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec




--
Regards= ,
Ahmad
--001a11c15f3a03934304f8a68014-- From nobody Mon May 5 06:09:25 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99D11A02A3 for ; Mon, 5 May 2014 06:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vmvu4tpZF6ea for ; Mon, 5 May 2014 06:09:17 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id D30EF1A008A for ; Mon, 5 May 2014 06:09:16 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 36444804DA; Mon, 5 May 2014 09:09:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1399295352; bh=eQtGb3RjUXKi2gJW2iG+XP+mhH1D1EMjPjdV0qV2HtA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=bueg6wJ1QNWY++atlc3Zcagz9RoSVlR6vt2gaHxJnHdSqF6FKPysAngEujh/9tb3f 6++yaqpFGgQQqhbhaD5acMQoZt4bSj1jJr+ZqUBcEs5ve0DqRNSXZi5f/SVoGqgNKk Hxw97iAWO+jxUhJkLck07oCCbW72Ar0EYBClClUw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s45D998N008255; Mon, 5 May 2014 09:09:11 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 5 May 2014 09:09:09 -0400 (EDT) From: Paul Wouters To: Syed Ajim Hussain In-Reply-To: <335B84BDA2818C428E63D9B0ADE6863545AF7A1A@szxeml561-mbx.china.huawei.com> Message-ID: References: <335B84BDA2818C428E63D9B0ADE6863545AF7228@szxeml561-mbx.china.huawei.com> <335B84BDA2818C428E63D9B0ADE6863545AF7A1A@szxeml561-mbx.china.huawei.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/1Wn0XvRRhrFSZ9KBeGoRH9091fA Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] Simultaneous Child SA Creation tigger from both the side. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 13:09:24 -0000 On Mon, 5 May 2014, Syed Ajim Hussain wrote: > Thanks for your reply, This problem happened in real scenario, problem is- both the Tunnel end points are different vendor, > They handle it differently. > > We can defined this behavior in RFC, > > Also we have some other scenarios, it will be better if we define these extreme case behavior also in RFC, > to make inter-op smooth. In libreswan (openswan) the daemon processes one packet at a time, so by definition one of the child SA's finishes before the other, no matter how close the timing is. It also has a feature "uniqueids" that would (dis)allow identical Child SA's, so the latter one establishing replaces the previous one established. I'm not convinced your issue is a protocol issue. It seems more like an implementation issue? If any of your endpoints involved libreswan/openswan, feel free to contact me. Paul From nobody Mon May 5 07:03:26 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43941A036B for ; Mon, 5 May 2014 07:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVcgKIaSuRiW for ; Mon, 5 May 2014 07:03:21 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id E8D291A0362 for ; Mon, 5 May 2014 07:03:20 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id q8so2766897lbi.41 for ; Mon, 05 May 2014 07:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5MOyfiQQI24HkTS13c8dVdY/0IwNm0dygnFW3AEoQqo=; b=nwDO7sTe2qYsVimKP1+/zY7NewaMDTyq6GntCTyHaAo7+tOwEqC9xOWxGR4BmGJrgE uvqpp8VCv7Am2avOOdago22aDWZtIYmyTvnG047zUhfcaWCYJdJg6DhIQ4gfEK6klIVv ZQ05oc3Q7OnP+bNPSjuxL7jf3v+VhJJWCj61QJrsZjfYvICazNmNrPSK6RZPw8lXdXrT FE1l7FOT79P4FEMNTPjAD4+1BS4OTO1OkuhJTVKZ6CGZbTIKf8omeTbnJAQsKKGMCc9I KIliZ7uI7Glqg0SC4AjZPyrSbK/vo4YLcVJvGksTM+H5nXYex9MbiAHYSVmucc47Tmit rLXw== X-Received: by 10.112.159.39 with SMTP id wz7mr1346651lbb.63.1399298596880; Mon, 05 May 2014 07:03:16 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:d5a4:211a:a8ec:b8ab? ([2001:1bc8:101:f101:d5a4:211a:a8ec:b8ab]) by mx.google.com with ESMTPSA id an10sm8362161lac.4.2014.05.05.07.03.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 May 2014 07:03:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Jouni In-Reply-To: Date: Mon, 5 May 2014 17:03:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <357CC5D9-48D2-4E4E-BB2F-5F002FF824C8@gmail.com> References: To: Ahmad Muhanna , vijay kn X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/uCEdeIa3sqxYUchM88CJfX4ssKg Cc: ipsec@ietf.org, kilian.weniger@googlemail.com, vjkumar2003@gmail.com Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 14:03:23 -0000 Just a thought.. would MOBIKE be any use here? At least one would be = able to move the SeGWs on fly (assuming the source and destination SeGW = are able to share required information between each other). - Jouni On May 5, 2014, at 3:45 PM, Ahmad Muhanna wrote: > Hi Vijay, >=20 > Please see comments inline. >=20 > On Mon, May 5, 2014 at 12:30 AM, vijay kn wrote: > Hi Ahmad, >=20 > If you meant re-negotiating is IKEv2 rekey then it will not work = because IKEv2 rekey will not send any IKE_SA_INIT packet. As of now, the = RFC says that REDIRECT_SUPPORTED payload can be sent only in IKE_SA_INIT = msg. >=20 > OR >=20 > If you meant re-negotiating is completely delete the current SA and = re-negotiate the SA from scratch, this would lead to service loss/pkt = loss. >=20 > =20 >=20 > [Ahmad] > Yes. I meant the later. >=20 > If we look at all scenarios that could be applicable to what you are = trying to solve, one end of the IKE SA needs to be upgraded to support = REDIRECTION. In my experience, that always happens in a controlled = environment (i.e., a maintenance window). In addition, operators do this = kind of activity very carefully and NOT globally; meaning, they upgrade = a limited number of nodes at a time or during a specific period. >=20 > The fact that the client and the SeGW -OR- the peers are from = different vendors or even in different operator domains for the sake of = making this more complex, it is always the case that when a new = functionality is introduced, there is an expectation of service = interruption. >=20 > NOW: even if we allow this feature as part of this RFC, there is still = no guarantee for the functionality to be successfully negotiated using = the proposed solution. Because that will introduce another level of = complexity and other backward compatibility scenarios that need to be = considered when one of the peers support this functionality and the = other does not. >=20 > For example: what about if the SeGW support REDIRECTION as per RFC5685 = but NOT by the newly introduced functionality (assuming that has been = adopted). Although, the SeGW support REDIRECTION, but it would NOT be = able to recognize and support this functionality. This means that it = wont work but renegotiation of the IKE SA will still work. >=20 > IMO, what you are trying to do is a completely new feature that is not = in the scope of this RFC and that is why I said this RFC does not need = to be updated or changed. I believe what you are trying to do is some = kind of dynamic mechanism that allow one peer to check with the other = peer on what kind of functionality it supports vs. what it does NOT = support with some forward compatibility in mind. > That is totally and completely different than this RFC and can be = applicable to many other scenarios and RFCs other than this one. >=20 > I hope I am making sense. >=20 > Regards, > Ahmad > =20 >=20 > Recommendation: - >=20 > Since the base stations normally establish Tunnel with other vendor = base stations and/or other vendor Gateways which may or may not support = REDIRECT, it is better to add this solution (client to send a new INFO = msg with the REDIRECT_SUPPORTED notify payload) to enable a SMOOTH = inter-op with other vendor implementations. >=20 > =20 >=20 > Because of these reasons, I feel the RFC needs correction. >=20 > =20 >=20 > =20 >=20 > From: Ahmad Muhanna [mailto:asmuhanna@gmail.com]=20 > Sent: Sunday, May 04, 2014 9:41 PM > To: vijay kn > Cc: vijay@wichorus.com; kilian.weniger@googlemail.com; ipsec@ietf.org; = vjkumar2003@gmail.com > Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC = 5685) >=20 > =20 >=20 > Hi, Vijay,=20 >=20 > =20 >=20 > I am NOT one if the authors of this RFC but I recall the discussion = and the use case. If I understand the scenario correctly, the client in = this case (eNB) negotiated an IKE SA without indicating the ability to = support REDIRECT. If that is the case, the client should renegotiate IKE = SA after being upgraded to support this functionality. My understanding = renegotiating IKE SA is supported. >=20 > =20 >=20 > IMO, I do not think that anything in this RFC needs to be changed. >=20 >=20 > Regards, >=20 > Ahmad Muhanna=20 >=20 >=20 > On May 2, 2014, at 9:14 AM, vijay kn wrote: >=20 > Hi, >=20 > There is an issue in IKEv2 REDIRECT RFC 5685. In one scenario, the = IKEv2 REDIRECT will not work indefinitely. >=20 > =20 >=20 > Scenario: - >=20 > Let=92s assume there are about 1000 clients connected to a IKEv2 = REDIRECT enabled SeGW. None of the clients were IKEv2 redirect enabled = at the time of establishing SA with the SeGW (meaning they have not sent = the REDIRECT_SUPPORTED notification in the >=20 > IKE_SA_INIT message) >=20 > This will lead to a situation where the SeGW is loaded and wanting to = redirect some clients to another SeGW but it cannot REDIRECT them as = none of them have indicated REDIRECT support in the IKE_SA_INIT message. >=20 > If the user/operator enabled REDIRECT functionality dynamically (like = after SAs were established), then the SeGW is not going to redirect them = because it had not received a REDIRECT_SUPPORTED payload from the = clients. >=20 > =20 >=20 > Effect/Impact: - >=20 > This leads to a congestion/overload at the gateway when the base = stations connecting to the SeGW are several hundred/thousands in number. = In the LTE and LTE-A scenarios, this condition is possible where the = number of base stations connecting to the SeGW are very high. >=20 > =20 >=20 > Suggestion/Solution: - >=20 > A change is required in RFC 5685 is required as below: - >=20 > =93=94Whenever the redirect feature/functionality is enabled at = run-time, the client should indicate the same to the SeGW. This can be = done by the client sending an INFORMATIONAL message under the = protection of the IKE SA. This message MUST have a REDIRECT_SUPPORTED = notify payload to enable the SeGW to redirect them at run-time even = though they had initially connected with SeGW without REDIRECT support=94=94= >=20 > =20 >=20 > Request for comments: - >=20 > Please read the problem, impact and solution listed above and let me = know if any comments. Hope my point is valid and needs to be = incorporated as the RFC update. >=20 > =20 >=20 > =20 >=20 > Regards, >=20 > Vijay N. >=20 > =20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 >=20 >=20 >=20 > --=20 > Regards, > Ahmad > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon May 5 09:29:18 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE981A03D9 for ; Mon, 5 May 2014 09:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxsIpIBEpRKX for ; Mon, 5 May 2014 09:29:05 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 006251A03AF for ; Mon, 5 May 2014 09:29:04 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id r5so1219116qcx.7 for ; Mon, 05 May 2014 09:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C2Ft/sg36LOZH9q521FCNRpOKhsuxz/YMj6WYpwKlm4=; b=j3wg+tmtQGbYsyxnnJpVgDI6MBy00dseXJL+LkUfZtg+DIk7hrakca7g84LaCMrQD7 zFJPotIhruwwmijUi4HN2bnY0pdRNZM9XtIFMummDXCoLwH6Up7Yu76s6lxnGywjKIyz 1QzgR9Pbsr1uX1uOmPBnZrUM3k0ZutMNezbvupmN4OtUN1CccqoQ1vbRYHaUlvaV1wdF X+VndNvUoU80IorXW4R1yywqXSfApqXy4OdI2X3m0QMHU3OMMTp9Puh9OgsTjuRIYTgA rVcN4KbIycIQnZJOpELQQQVcJDv2tN5+ZA0hzmpX7xpGecIHFG6iT+8KosmAZqEzIIns UYDw== MIME-Version: 1.0 X-Received: by 10.140.108.4 with SMTP id i4mr43535182qgf.80.1399307341217; Mon, 05 May 2014 09:29:01 -0700 (PDT) Received: by 10.140.84.7 with HTTP; Mon, 5 May 2014 09:29:01 -0700 (PDT) In-Reply-To: <357CC5D9-48D2-4E4E-BB2F-5F002FF824C8@gmail.com> References: <357CC5D9-48D2-4E4E-BB2F-5F002FF824C8@gmail.com> Date: Mon, 5 May 2014 11:29:01 -0500 Message-ID: From: Ahmad Muhanna To: Jouni Content-Type: multipart/alternative; boundary=001a1139573e0144ed04f8a9a16d Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/x31pp66PllA2K87dujeiwOSRT5A Cc: "ipsec@ietf.org" , "kilian.weniger@googlemail.com" , Vijay Kumar , vijay kn Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 16:29:10 -0000 --001a1139573e0144ed04f8a9a16d Content-Type: text/plain; charset=ISO-8859-1 Hello Jouni, If my understanding is correct, MOBIKE allows the client to move its IKE tunnel from one SeGW to another based on Handover, for example. A multihoming IKE, if I may say. What Vijay is trying to address (at least this is my understanding) here is the scenario from the other end. When the SeGW is overloaded and would like to REDIRECT the client to another SeGW. The client won't know the condition at the SeGW and the SeGW is the one who initiates the proposed move. Regards, Ahmad On Mon, May 5, 2014 at 9:03 AM, Jouni wrote: > > Just a thought.. would MOBIKE be any use here? At least one would be able > to move the SeGWs on fly (assuming the source and destination SeGW are able > to share required information between each other). > > - Jouni > > On May 5, 2014, at 3:45 PM, Ahmad Muhanna wrote: > > > Hi Vijay, > > > > Please see comments inline. > > > > On Mon, May 5, 2014 at 12:30 AM, vijay kn wrote: > > Hi Ahmad, > > > > If you meant re-negotiating is IKEv2 rekey then it will not work because > IKEv2 rekey will not send any IKE_SA_INIT packet. As of now, the RFC says > that REDIRECT_SUPPORTED payload can be sent only in IKE_SA_INIT msg. > > > > OR > > > > If you meant re-negotiating is completely delete the current SA and > re-negotiate the SA from scratch, this would lead to service loss/pkt loss. > > > > > > > > [Ahmad] > > Yes. I meant the later. > > > > If we look at all scenarios that could be applicable to what you are > trying to solve, one end of the IKE SA needs to be upgraded to support > REDIRECTION. In my experience, that always happens in a controlled > environment (i.e., a maintenance window). In addition, operators do this > kind of activity very carefully and NOT globally; meaning, they upgrade a > limited number of nodes at a time or during a specific period. > > > > The fact that the client and the SeGW -OR- the peers are from different > vendors or even in different operator domains for the sake of making this > more complex, it is always the case that when a new functionality is > introduced, there is an expectation of service interruption. > > > > NOW: even if we allow this feature as part of this RFC, there is still > no guarantee for the functionality to be successfully negotiated using the > proposed solution. Because that will introduce another level of complexity > and other backward compatibility scenarios that need to be considered when > one of the peers support this functionality and the other does not. > > > > For example: what about if the SeGW support REDIRECTION as per RFC5685 > but NOT by the newly introduced functionality (assuming that has been > adopted). Although, the SeGW support REDIRECTION, but it would NOT be able > to recognize and support this functionality. This means that it wont work > but renegotiation of the IKE SA will still work. > > > > IMO, what you are trying to do is a completely new feature that is not > in the scope of this RFC and that is why I said this RFC does not need to > be updated or changed. I believe what you are trying to do is some kind of > dynamic mechanism that allow one peer to check with the other peer on what > kind of functionality it supports vs. what it does NOT support with some > forward compatibility in mind. > > That is totally and completely different than this RFC and can be > applicable to many other scenarios and RFCs other than this one. > > > > I hope I am making sense. > > > > Regards, > > Ahmad > > > > > > Recommendation: - > > > > Since the base stations normally establish Tunnel with other vendor base > stations and/or other vendor Gateways which may or may not support > REDIRECT, it is better to add this solution (client to send a new INFO msg > with the REDIRECT_SUPPORTED notify payload) to enable a SMOOTH inter-op > with other vendor implementations. > > > > > > > > Because of these reasons, I feel the RFC needs correction. > > > > > > > > > > > > From: Ahmad Muhanna [mailto:asmuhanna@gmail.com] > > Sent: Sunday, May 04, 2014 9:41 PM > > To: vijay kn > > Cc: vijay@wichorus.com; kilian.weniger@googlemail.com; ipsec@ietf.org; > vjkumar2003@gmail.com > > Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC > 5685) > > > > > > > > Hi, Vijay, > > > > > > > > I am NOT one if the authors of this RFC but I recall the discussion and > the use case. If I understand the scenario correctly, the client in this > case (eNB) negotiated an IKE SA without indicating the ability to support > REDIRECT. If that is the case, the client should renegotiate IKE SA after > being upgraded to support this functionality. My understanding > renegotiating IKE SA is supported. > > > > > > > > IMO, I do not think that anything in this RFC needs to be changed. > > > > > > Regards, > > > > Ahmad Muhanna > > > > > > On May 2, 2014, at 9:14 AM, vijay kn wrote: > > > > Hi, > > > > There is an issue in IKEv2 REDIRECT RFC 5685. In one scenario, the IKEv2 > REDIRECT will not work indefinitely. > > > > > > > > Scenario: - > > > > Let's assume there are about 1000 clients connected to a IKEv2 REDIRECT > enabled SeGW. None of the clients were IKEv2 redirect enabled at the time > of establishing SA with the SeGW (meaning they have not sent the > REDIRECT_SUPPORTED notification in the > > > > IKE_SA_INIT message) > > > > This will lead to a situation where the SeGW is loaded and wanting to > redirect some clients to another SeGW but it cannot REDIRECT them as none > of them have indicated REDIRECT support in the IKE_SA_INIT message. > > > > If the user/operator enabled REDIRECT functionality dynamically (like > after SAs were established), then the SeGW is not going to redirect them > because it had not received a REDIRECT_SUPPORTED payload from the clients. > > > > > > > > Effect/Impact: - > > > > This leads to a congestion/overload at the gateway when the base > stations connecting to the SeGW are several hundred/thousands in number. In > the LTE and LTE-A scenarios, this condition is possible where the number of > base stations connecting to the SeGW are very high. > > > > > > > > Suggestion/Solution: - > > > > A change is required in RFC 5685 is required as below: - > > > > ""Whenever the redirect feature/functionality is enabled at run-time, > the client should indicate the same to the SeGW. This can be done by the > client sending an INFORMATIONAL message under the protection of the IKE > SA. This message MUST have a REDIRECT_SUPPORTED notify payload to enable > the SeGW to redirect them at run-time even though they had initially > connected with SeGW without REDIRECT support"" > > > > > > > > Request for comments: - > > > > Please read the problem, impact and solution listed above and let me > know if any comments. Hope my point is valid and needs to be incorporated > as the RFC update. > > > > > > > > > > > > Regards, > > > > Vijay N. > > > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > -- > > Regards, > > Ahmad > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > -- Regards, Ahmad --001a1139573e0144ed04f8a9a16d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Jouni,

If my understanding is cor= rect, MOBIKE allows the client to move its IKE tunnel from one SeGW to anot= her based on Handover, for example. A multihoming IKE, if I may say.
What Vijay is trying to address (at least this is my understanding) he= re is the scenario from the other end. When the SeGW is overloaded and woul= d like to REDIRECT the client to another SeGW. The client won't know th= e condition at the SeGW and the SeGW is the one who initiates the proposed = move.

Regards,
Ahmad



On Mon= , May 5, 2014 at 9:03 AM, Jouni <jouni.nospam@gmail.com> wrote:

Just a thought.. would MOBIKE be any use here? At least one would be able t= o move the SeGWs on fly (assuming the source and destination SeGW are able = to share required information between each other).

- Jouni

On May 5, 2014, at 3:45 PM, Ahmad Muhanna wrote:

> Hi Vijay,
>
> Please see comments inline.
>
> On Mon, May 5, 2014 at 12:30 AM, vijay kn <vijay.kn@huawei.com> wrote:
> Hi Ahmad,
>
> If you meant re-negotiating is IKEv2 rekey then it will not work becau= se IKEv2 rekey will not send any IKE_SA_INIT packet. As of now, the RFC say= s that REDIRECT_SUPPORTED payload can be sent only in IKE_SA_INIT msg.
>
> OR
>
> If you meant re-negotiating is completely delete the current SA and re= -negotiate the SA from scratch, this would lead to service loss/pkt loss. >
>
>
> [Ahmad]
> Yes. I meant the later.
>
> If we look at all scenarios that could be applicable to what you are t= rying to solve, one end of the IKE SA needs to be upgraded to support REDIR= ECTION. In my experience, that always happens in a controlled environment (= i.e., a maintenance window). In addition, operators do this kind of activit= y very carefully and NOT globally; meaning, they upgrade a limited number o= f nodes at a time or during a specific period.
>
> The fact that the client and the SeGW -OR- the peers are from differen= t vendors or even in different operator domains for the sake of making this= more complex, it is always the case that when a new functionality is intro= duced, there is an expectation of service interruption.
>
> NOW: even if we allow this feature as part of this RFC, there is still= no guarantee for the functionality to be successfully negotiated using the= proposed solution. Because that will introduce another level of complexity= and other backward compatibility scenarios that need to be considered when= one of the peers support this functionality and the other does not.
>
> For example: what about if the SeGW support REDIRECTION as per RFC5685= but NOT by the newly introduced functionality (assuming that has been adop= ted). Although, the SeGW support REDIRECTION, but it would NOT be able to r= ecognize and support this functionality. This means that it wont work but r= enegotiation of the IKE SA will still work.
>
> IMO, what you are trying to do is a completely new feature that is not= in the scope of this RFC and that is why I said this RFC does not need to = be updated or changed. I believe what you are trying to do is some kind of = dynamic mechanism that allow one peer to check with the other peer on what = kind of functionality it supports vs. what it does NOT support with some fo= rward compatibility in mind.
> That is totally and completely different than this RFC and can be appl= icable to many other scenarios and RFCs other than this one.
>
> I hope I am making sense.
>
> Regards,
> Ahmad
>
>
> Recommendation: -
>
> Since the base stations normally establish Tunnel with other vendor ba= se stations and/or other vendor Gateways which may or may not support  = ;REDIRECT, it is better to add this solution (client to send a new INFO msg= with the REDIRECT_SUPPORTED notify payload) to enable a SMOOTH inter-op wi= th other vendor implementations.
>
>
>
> Because of these reasons, I feel the RFC needs correction.
>
>
>
>
>
> From: Ahmad Muhanna [mailto:asm= uhanna@gmail.com]
> Sent: Sunday, May 04, 2014 9:41 PM
> To: vijay kn
> Cc: vijay@wichorus.com; kilian.weniger@googlemail.com<= /a>; ipsec@ietf.org; vjkumar2003@gmail.com
> Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5= 685)
>
>
>
> Hi, Vijay,
>
>
>
> I am NOT one if the authors of this RFC but I recall the discussion an= d the use case. If I understand the scenario correctly, the client in this = case (eNB) negotiated an IKE SA without indicating the ability to support R= EDIRECT. If that is the case, the client should renegotiate IKE SA after be= ing upgraded to support this functionality. My understanding renegotiating = IKE SA is supported.
>
>
>
> IMO, I do not think that anything in this RFC needs to be changed.
>
>
> Regards,
>
> Ahmad Muhanna
>
>
> On May 2, 2014, at 9:14 AM, vijay kn <vijay.kn@huawei.com> wrote:
>
> Hi,
>
> There is an issue in IKEv2 REDIRECT RFC 5685. In one scenario, the IKE= v2 REDIRECT will not work indefinitely.
>
>
>
> Scenario: -
>
> Let’s assume there are about 1000 clients connected to a IKEv2 R= EDIRECT enabled SeGW. None of the clients were IKEv2 redirect enabled at th= e time of establishing SA with the SeGW (meaning they have not sent the RED= IRECT_SUPPORTED notification in the
>
> IKE_SA_INIT message)
>
> This will lead to a situation where the SeGW is loaded and wanting to = redirect some clients to another SeGW but it cannot REDIRECT them as none o= f them have indicated REDIRECT support in the IKE_SA_INIT message.
>
> If the user/operator enabled REDIRECT functionality dynamically (like = after SAs were established), then the SeGW is not going to redirect them be= cause it had not received a REDIRECT_SUPPORTED payload from the clients. >
>
>
> Effect/Impact: -
>
> This leads to a congestion/overload at the gateway when the base stati= ons connecting to the SeGW are several hundred/thousands in number. In the = LTE and LTE-A scenarios, this condition is possible where the number of bas= e stations connecting to the SeGW are very high.
>
>
>
> Suggestion/Solution: -
>
> A change is required in RFC 5685 is required as below: -
>
> “”Whenever the redirect feature/functionality is enabled a= t run-time, the client should indicate the same to the SeGW. This can be do= ne by the client sending an INFORMATIONAL message  under the protectio= n of the IKE SA. This message MUST have a REDIRECT_SUPPORTED notify payload= to enable the SeGW to redirect them at run-time even though they had initi= ally connected with SeGW without REDIRECT support””
>
>
>
> Request for comments: -
>
> Please read the problem, impact and solution listed above and let me k= now if any comments. Hope my point is valid and needs to be incorporated as= the RFC update.
>
>
>
>
>
> Regards,
>
> Vijay N.
>
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
>
>
> --
> Regards,
> Ahmad
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec




--
Regards,
Ahmad
--001a1139573e0144ed04f8a9a16d-- From nobody Mon May 5 10:06:01 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82BF1A03AF for ; Mon, 5 May 2014 10:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpuIMFerej5Z for ; Mon, 5 May 2014 10:05:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) by ietfa.amsl.com (Postfix) with ESMTP id 32CC21A03AC for ; Mon, 5 May 2014 10:05:54 -0700 (PDT) Received: from CO2PR05MB665.namprd05.prod.outlook.com (10.141.230.11) by CO2PR05MB668.namprd05.prod.outlook.com (10.141.230.25) with Microsoft SMTP Server (TLS) id 15.0.929.12; Mon, 5 May 2014 17:05:50 +0000 Received: from CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) by CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) with mapi id 15.00.0929.001; Mon, 5 May 2014 17:05:50 +0000 From: Praveen Sathyanarayan To: vijay kn , Ahmad Muhanna Thread-Topic: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) Thread-Index: Ac9mCR4Wj8NaQqRJSGu1iyUmq2WiKQAB4oDwAGiwcoAAG+mzgAAJoIEA Date: Mon, 5 May 2014 17:05:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.239.10] x-forefront-prvs: 0202D21D2F x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(164054003)(199002)(189002)(24454002)(377454003)(76176999)(92726001)(4396001)(19580405001)(92566001)(20776003)(76482001)(18717965001)(101416001)(16236675002)(74502001)(86362001)(99286001)(19580395003)(87936001)(83322001)(50986999)(99396002)(15975445006)(81342001)(74662001)(31966008)(81542001)(66066001)(77096999)(83506001)(54356999)(79102001)(19300405004)(77982001)(83072002)(15202345003)(80022001)(2656002)(46102001)(36756003)(85852003); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB668; H:CO2PR05MB665.namprd05.prod.outlook.com; FPR:CEFCF13F.ACD25392.99D3519B.44E8EB49.2047A; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_CF8D08A75371Epraveenysjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/AQ9SZ1aoRjcA8JyBYfZ_h0ppNbw Cc: "ipsec@ietf.org" , "vijay@wichorus.com" , "kilian.weniger@googlemail.com" , "vjkumar2003@gmail.com" Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 17:06:00 -0000 --_000_CF8D08A75371Epraveenysjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Why not trigger Re-authentication from base station, when upgraded/REDIRECT= enabled in config? RFC 5996: Reauthentication is done by creating a new IKE SA from scratch (using IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA Notify payloads), creating new Child SAs within the new IKE SA (without REKEY_SA Notify payloads), and finally deleting the old IKE SA (which deletes the old Child SAs as well). Thanks, Praveen From: vijay kn > Date: Sunday, May 4, 2014 at 10:30 PM To: Ahmad Muhanna > Cc: "ipsec@ietf.org" >, "vijay@wichorus.com" >, "kilian.weniger@googlemail.com" >, "vjkumar2003@gmail.com= " > Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) Hi Ahmad, If you meant re-negotiating is IKEv2 rekey then it will not work because IK= Ev2 rekey will not send any IKE_SA_INIT packet. As of now, the RFC says tha= t REDIRECT_SUPPORTED payload can be sent only in IKE_SA_INIT msg. OR If you meant re-negotiating is completely delete the current SA and re-nego= tiate the SA from scratch, this would lead to service loss/pkt loss. Recommendation: - Since the base stations normally establish Tunnel with other vendor base st= ations and/or other vendor Gateways which may or may not support REDIRECT,= it is better to add this solution (client to send a new INFO msg with the = REDIRECT_SUPPORTED notify payload) to enable a SMOOTH inter-op with other v= endor implementations. Because of these reasons, I feel the RFC needs correction. From: Ahmad Muhanna [mailto:asmuhanna@gmail.com] Sent: Sunday, May 04, 2014 9:41 PM To: vijay kn Cc: vijay@wichorus.com; kilian.weniger@googlemai= l.com; ipsec@ietf.org; vjkumar2003@gmail.com Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) Hi, Vijay, I am NOT one if the authors of this RFC but I recall the discussion and the= use case. If I understand the scenario correctly, the client in this case = (eNB) negotiated an IKE SA without indicating the ability to support REDIRE= CT. If that is the case, the client should renegotiate IKE SA after being u= pgraded to support this functionality. My understanding renegotiating IKE S= A is supported. IMO, I do not think that anything in this RFC needs to be changed. Regards, Ahmad Muhanna On May 2, 2014, at 9:14 AM, vijay kn > wrote: Hi, There is an issue in IKEv2 REDIRECT RFC 5685. In one scenario, the IKEv2 RE= DIRECT will not work indefinitely. Scenario: - Let's assume there are about 1000 clients connected to a IKEv2 REDIRECT ena= bled SeGW. None of the clients were IKEv2 redirect enabled at the time of e= stablishing SA with the SeGW (meaning they have not sent the REDIRECT_SUPPO= RTED notification in the IKE_SA_INIT message) This will lead to a situation where the SeGW is loaded and wanting to redir= ect some clients to another SeGW but it cannot REDIRECT them as none of the= m have indicated REDIRECT support in the IKE_SA_INIT message. If the user/operator enabled REDIRECT functionality dynamically (like after= SAs were established), then the SeGW is not going to redirect them because= it had not received a REDIRECT_SUPPORTED payload from the clients. Effect/Impact: - This leads to a congestion/overload at the gateway when the base stations c= onnecting to the SeGW are several hundred/thousands in number. In the LTE a= nd LTE-A scenarios, this condition is possible where the number of base sta= tions connecting to the SeGW are very high. Suggestion/Solution: - A change is required in RFC 5685 is required as below: - ""Whenever the redirect feature/functionality is enabled at run-time, the c= lient should indicate the same to the SeGW. This can be done by the client = sending an INFORMATIONAL message under the protection of the IKE SA. This = message MUST have a REDIRECT_SUPPORTED notify payload to enable the SeGW to= redirect them at run-time even though they had initially connected with Se= GW without REDIRECT support"" Request for comments: - Please read the problem, impact and solution listed above and let me know i= f any comments. Hope my point is valid and needs to be incorporated as the = RFC update. Regards, Vijay N. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_CF8D08A75371Epraveenysjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Why not trigger Re-authentication from base station, when upgraded/RED= IRECT enabled in config?

RFC 5996:

   Reauthentication is done by creati=
ng a new IKE SA from scratch (using
   IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA Notify
   payloads), creating new Child SAs within the new IKE SA (without
   REKEY_SA Notify payloads), and finally deleting the old IKE SA (w=
hich
   deletes the old Child SAs as well).

Thanks,
Praveen

From: vijay kn <vijay.kn@huawei.com>
Date: Sunday, May 4, 2014 at 10:30 = PM
To: Ahmad Muhanna <asmuhanna@gmail.com>
Cc: "ipsec@ietf.org" <ips= ec@ietf.org>, "vijay@wich= orus.com" <vijay@wichorus= .com>, "kilian.weniger@goog= lemail.com" <k= ilian.weniger@googlemail.com>, "vjkumar2003@gmail.com" <vjkumar2003@gmail.com>
Subject: Re: [IPsec] Regarding IKEv= 2 REDIRECT problem (reference RFC 5685)

Hi Ahmad,

If you meant re-negoti= ating is IKEv2 rekey then it will not work because IKEv2 rekey will not sen= d any IKE_SA_INIT packet. As of now, the RFC says that REDIRECT_SUPPORTED p= ayload can be sent only in IKE_SA_INIT msg.

OR

If you meant re-negoti= ating is completely delete the current SA and re-negotiate the SA from scra= tch, this would lead to service loss/pkt loss.

 

Recommendation: -

Since the base stations normally establish Tunnel with other= vendor base stations and/or other vendor Gateways which may or may not sup= port  REDIRECT, it is better to add this solution (client to send a new INFO msg with the REDIRECT_SUPPORTED notify= payload) to enable a SMOOTH inter-op with other vendor implementations.

 

Because of these reaso= ns, I feel the RFC needs correction.

 

 

From: Ahmad Muhanna [mailto:asmuhanna@gmail.com]
Sent: Sunday, May 04, 2014 9:41 PM
To: vijay kn
Cc: vijay@wichorus.com; kilian.weniger@googlemail.com; ipsec@= ietf.org; vjkumar2003@gmail.com
Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC= 5685)

 

Hi, Vijay, 

 

I am NOT one if the authors of this RFC but I recall= the discussion and the use case. If I understand the scenario correctly, t= he client in this case (eNB) negotiated an IKE SA without indicating the ab= ility to support REDIRECT. If that is the case, the client should renegotiate IKE SA after being upgraded to = support this functionality. My understanding renegotiating IKE SA is suppor= ted.

 

IMO, I do not think that anything in this RFC needs = to be changed.


Regards,

Ahmad Muhanna 


On May 2, 2014, at 9:14 AM, vijay kn <vijay.kn@huawei.com> wrote:

Hi,

There is an issue in I= KEv2 REDIRECT RFC 5685. In one scenario, the IKEv2 REDIRECT will not= work indefinitely.

 

Scenario: -

Let’s assume there are about 1000 clients conn= ected to a IKEv2 REDIRECT enabled SeGW. None of the clients were IKEv2 redirect enabled at the time of establish= ing SA with the SeGW (meaning they have not sent the REDIRECT_SUPPORTED= notification in the

IKE_SA_INIT message)

This will lead to a situation where the SeGW is load= ed and wanting to redirect some clients to another SeGW but it cannot REDIR= ECT them as none of them have indicated REDIRECT support in the IKE_SA_INIT= message.

If the user/operator enabled REDIRECT functionality = dynamically (like after SAs were established), then the SeGW is not going t= o redirect them because it had not received a REDIRECT_SUPPORTED payload fr= om the clients.

 

Effect/Impact: -

This leads to a congestion/overload at the gateway w= hen the base stations connecting to the SeGW are several hundred/thousands = in number. In the LTE and LTE-A scenarios, this condition is possible where= the number of base stations connecting to the SeGW are very high.

 

Suggestion/Solution: -

A change is required in RFC 5685 is required as belo= w: -

“”Whenever= the redirect feature/functionality is enabled at run-time, the client shou= ld indicate the same to the SeGW. This can be done by the client sending an= INFORMATIONAL message  under the protection of the IKE SA. This message MUST have a REDIRECT_SUPPORTED notify payload to = enable the SeGW to redirect them at run-time even though they had initially= connected with SeGW without REDIRECT support””

 

Request for comments: -

Please read the problem, impact and solution listed = above and let me know if any comments. Hope my point is valid and needs to = be incorporated as the RFC update.

 

 

Regards,

Vijay N.

 

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

 --_000_CF8D08A75371Epraveenysjunipernet_-- From nobody Mon May 5 10:18:19 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA761A02E9 for ; Mon, 5 May 2014 10:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLUt37VQdyIL for ; Mon, 5 May 2014 10:18:10 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9B49F1A00D7 for ; Mon, 5 May 2014 10:18:10 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id x13so30846qcv.5 for ; Mon, 05 May 2014 10:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qDTFKyiPEz6FtqmTfRlyuAAzDZjiGRPQn/R0QtKQgSo=; b=dAl4Qd+KAM3nFqalUbUPVJBME9BehTbWUn7e8IzenZEU0+PF0YvwNV6+nOzcNf/gIj MZnm43KJ5rXFfgLOO+BxkLzHjw+WDb5KkTvBWpT0gfpfHnI2g9G2ZeQDSJ2uy0fge5uE o6oV2NEVcB/gS3srQI1ubDCKqAHPCMEtKajCcHqUcdiZEqWwK8cu+A5kFzvgW5GOkA0O XWbM5CxACSUgmvaeUyyOs/y7rM+O716oo07Gdv13o7F8qUmbO6lmSXwo1j+LHVs5kb/b +SGuFB7Fzcb1YzVE7E0taX3MIYlsqIqyS9mI4s9BAEEsvn1aX3MBFHQyQHOPgZpygXMn 8hZg== MIME-Version: 1.0 X-Received: by 10.224.138.3 with SMTP id y3mr46829025qat.78.1399310275143; Mon, 05 May 2014 10:17:55 -0700 (PDT) Received: by 10.140.84.7 with HTTP; Mon, 5 May 2014 10:17:54 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 May 2014 12:17:54 -0500 Message-ID: From: Ahmad Muhanna To: Praveen Sathyanarayan Content-Type: multipart/alternative; boundary=047d7b672b44e1709d04f8aa4f07 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/OhBAPnozeDsPUxl6Jg62T_0yiEA Cc: "ipsec@ietf.org" , "vijay@wichorus.com" , "kilian.weniger@googlemail.com" , "vjkumar2003@gmail.com" , vijay kn Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 17:18:15 -0000 --047d7b672b44e1709d04f8aa4f07 Content-Type: text/plain; charset=ISO-8859-1 Thanks Praveen for pointing that out. That what I initially had in mind but got distracted by the notion that it may cause service disruption without double checking RFC5996. I believe Re-authentication is the solution for this issue without causing any service disruption. Although, service disruption is imminent in case of upgrade anyway. Regards, Ahmad On Mon, May 5, 2014 at 12:05 PM, Praveen Sathyanarayan < praveenys@juniper.net> wrote: > Why not trigger Re-authentication from base station, when > upgraded/REDIRECT enabled in config? > > RFC 5996: > > Reauthentication is done by creating a new IKE SA from scratch (using > IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA Notify > payloads), creating new Child SAs within the new IKE SA (without > REKEY_SA Notify payloads), and *finally deleting the old IKE SA* (which > deletes the old Child SAs as well). > > > Thanks, > Praveen > > From: vijay kn > Date: Sunday, May 4, 2014 at 10:30 PM > To: Ahmad Muhanna > Cc: "ipsec@ietf.org" , "vijay@wichorus.com" < > vijay@wichorus.com>, "kilian.weniger@googlemail.com" < > kilian.weniger@googlemail.com>, "vjkumar2003@gmail.com" < > vjkumar2003@gmail.com> > Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) > > Hi Ahmad, > > If you meant re-negotiating is IKEv2 rekey then it will not work because > IKEv2 rekey will not send any IKE_SA_INIT packet. As of now, the RFC says > that REDIRECT_SUPPORTED payload can be sent only in IKE_SA_INIT msg. > > OR > > If you meant re-negotiating is completely delete the current SA and > re-negotiate the SA from scratch, this would lead to service loss/pkt loss. > > > > *Recommendation: -* > > Since the base stations normally establish Tunnel with other vendor base > stations and/or other vendor Gateways which may or may not support > REDIRECT, it is better to add this solution (client to send a new INFO msg > with the REDIRECT_SUPPORTED notify payload) to enable a SMOOTH inter-op > with other vendor implementations. > > > > Because of these reasons, I feel the RFC needs correction. > > > > > > *From:* Ahmad Muhanna [mailto:asmuhanna@gmail.com ] > *Sent:* Sunday, May 04, 2014 9:41 PM > *To:* vijay kn > *Cc:* vijay@wichorus.com; kilian.weniger@googlemail.com; ipsec@ietf.org; > vjkumar2003@gmail.com > *Subject:* Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC > 5685) > > > > Hi, Vijay, > > > > I am NOT one if the authors of this RFC but I recall the discussion and > the use case. If I understand the scenario correctly, the client in this > case (eNB) negotiated an IKE SA without indicating the ability to support > REDIRECT. If that is the case, the client should renegotiate IKE SA after > being upgraded to support this functionality. My understanding > renegotiating IKE SA is supported. > > > > IMO, I do not think that anything in this RFC needs to be changed. > > > Regards, > > Ahmad Muhanna > > > On May 2, 2014, at 9:14 AM, vijay kn wrote: > > Hi, > > There is an issue in IKEv2 REDIRECT RFC 5685. In one scenario, the IKEv2 > REDIRECT will not work indefinitely. > > > > *Scenario: -* > > Let's assume there are about 1000 clients connected to a IKEv2 REDIRECT > enabled SeGW. *None of the clients were IKEv2 redirect enabled at the > time of establishing SA* with the SeGW (meaning they have not sent the > REDIRECT_SUPPORTED notification in the > > IKE_SA_INIT message) > > This will lead to a situation where the SeGW is loaded and wanting to > redirect some clients to another SeGW but it cannot REDIRECT them as none > of them have indicated REDIRECT support in the IKE_SA_INIT message. > > If the user/operator enabled REDIRECT functionality dynamically (like > after SAs were established), then the SeGW is not going to redirect them > because it had not received a REDIRECT_SUPPORTED payload from the clients. > > > > *Effect/Impact: -* > > This leads to a congestion/overload at the gateway when the base stations > connecting to the SeGW are several hundred/thousands in number. In the LTE > and LTE-A scenarios, this condition is possible where the number of base > stations connecting to the SeGW are very high. > > > > *Suggestion/Solution: -* > > A change is required in RFC 5685 is required as below: - > > ""Whenever the redirect feature/functionality is enabled at run-time, the > client should indicate the same to the SeGW. This can be done by the client > sending an INFORMATIONAL message under the protection of the IKE SA. This > message MUST have a REDIRECT_SUPPORTED notify payload to enable the SeGW to > redirect them at run-time even though they had initially connected with > SeGW without REDIRECT support"" > > > > *Request for comments: -* > > Please read the problem, impact and solution listed above and let me know > if any comments. Hope my point is valid and needs to be incorporated as the > RFC update. > > > > > > Regards, > > Vijay N. > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > -- Regards, Ahmad --047d7b672b44e1709d04f8aa4f07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Praveen for pointing that out.

That wh= at I initially had in mind but got distracted by the notion that it may cau= se service disruption without double checking RFC5996.
I believe = Re-authentication is the solution for this issue without causing any servic= e disruption. Although, service disruption is imminent in case of upgrade a= nyway.

Regards,
Ahmad


On Mon, May 5, 2014 at 12:= 05 PM, Praveen Sathyanarayan <praveenys@juniper.net> wro= te:
Why not trigger Re-authentication from base station, when upgraded/RED= IRECT enabled in config?

RFC 5996:

   Reauthenti=
cation is done by creating a new IKE SA from scratch (using
   IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA Notify
   payloads), creating new Child SAs within the new IKE SA (without
   REKEY_SA Notify payloads), and finally deleting the old IKE SA (w=
hich
   deletes the old Child SAs as well).

Thanks,
Praveen

From: vijay kn <vijay.kn@huawei.com>
Date: Sunday, May 4, 2014 at 10:30 = PM
To: Ahmad Muhanna <asmuhanna@gmail.com>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, "vijay@wichorus.com" &l= t;vijay@wichorus.co= m>, "k= ilian.weniger@googlemail.com" <kilian.weniger@googlemail.com>, &= quot;vjkumar2003= @gmail.com" <vjkumar2003@gmail.com>
Subject: Re: [IPsec] Regarding IKEv= 2 REDIRECT problem (reference RFC 5685)

Hi Ahmad,

If you meant re-negoti= ating is IKEv2 rekey then it will not work because IKEv2 rekey will not sen= d any IKE_SA_INIT packet. As of now, the RFC says that REDIRECT_SUPPORTED p= ayload can be sent only in IKE_SA_INIT msg.

OR

If you meant re-negoti= ating is completely delete the current SA and re-negotiate the SA from scra= tch, this would lead to service loss/pkt loss.

 

Recommendation: -

Since the base stations normally establish Tunnel with other= vendor base stations and/or other vendor Gateways which may or may not sup= port  REDIRECT, it is better to add this solution (client to send a new INFO msg with the REDIRECT_SUPPORTED notify= payload) to enable a SMOOTH inter-op with other vendor implementations.=

 

Because of these reaso= ns, I feel the RFC needs correction.

 

 

From: Ahmad Muhanna [mailto:asmuhanna@gmail.com]
Sent: Sunday, May 04, 2014 9:41 PM
To: vijay kn
Cc: vijay@wi= chorus.com; kilian.weniger@googlemail.com; ipsec@ietf.org; vjkumar2003@gmai= l.com
Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC= 5685)

 

Hi, Vijay, 

 

I am NOT one if the authors of this RFC but I recall= the discussion and the use case. If I understand the scenario correctly, t= he client in this case (eNB) negotiated an IKE SA without indicating the ab= ility to support REDIRECT. If that is the case, the client should renegotiate IKE SA after being upgraded to = support this functionality. My understanding renegotiating IKE SA is suppor= ted.

 

IMO, I do not think that anything in this RFC needs = to be changed.


Regards,

Ahmad Muhanna 


On May 2, 2014, at 9:14 AM, vijay kn <vijay.kn@huawei.com> wrote:

Hi,

There is an issue in I= KEv2 REDIRECT RFC 5685. In one scenario, the IKEv2 REDIRECT will not= work indefinitely.

 

Scenario: -

Let’s assume there are about 1000 clients conn= ected to a IKEv2 REDIRECT enabled SeGW. None of the clients were IKEv2 redirect enabled at the time of establish= ing SA with the SeGW (meaning they have not sent the REDIRECT_SUPPORTED= notification in the

IKE_SA_INIT message)

This will lead to a situation where the SeGW is load= ed and wanting to redirect some clients to another SeGW but it cannot REDIR= ECT them as none of them have indicated REDIRECT support in the IKE_SA_INIT= message.

If the user/operator enabled REDIRECT functionality = dynamically (like after SAs were established), then the SeGW is not going t= o redirect them because it had not received a REDIRECT_SUPPORTED payload fr= om the clients.

 

Effect/Impact: -

This leads to a congestion/overload at the gateway w= hen the base stations connecting to the SeGW are several hundred/thousands = in number. In the LTE and LTE-A scenarios, this condition is possible where= the number of base stations connecting to the SeGW are very high.

 

Suggestion/Solution: -

A change is required in RFC 5685 is required as belo= w: -

“”Whenever= the redirect feature/functionality is enabled at run-time, the client shou= ld indicate the same to the SeGW. This can be done by the client sending an= INFORMATIONAL message  under the protection of the IKE SA. This message MUST have a REDIRECT_SUPPORTED notify payload to = enable the SeGW to redirect them at run-time even though they had initially= connected with SeGW without REDIRECT support””

 

Request for comments: -

Please read the problem, impact and solution listed = above and let me know if any comments. Hope my point is valid and needs to = be incorporated as the RFC update.

 

 

Regards,

Vijay N.

 

_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec



--
Regards= ,
Ahmad
--047d7b672b44e1709d04f8aa4f07-- From nobody Mon May 5 12:53:27 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066E51A047C for ; Mon, 5 May 2014 12:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfdN-YsQC8LK for ; Mon, 5 May 2014 12:53:24 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5D61A0452 for ; Mon, 5 May 2014 12:53:24 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 21007674058 for ; Mon, 5 May 2014 12:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=6CnpMOG4RZacSh2wHjVb WpMqM8E=; b=hehCSZ17W4IHo+of38x71DSq7Mn4V5YY3ZbxVo4l/5HZkmYvJEYn TMBUI6xuGH8CFozAixzl/K5Kw71LV1oHMPT2FkZ86yc1kbb+BkCYJoKAOejl6WA3 Li7WGsnBCYXMTr78JWcnxXHSNiHw64Gasv2PjrZO5nvNntVfpBSOlDM= Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id C92CB674060 for ; Mon, 5 May 2014 12:53:20 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id m15so4398698wgh.4 for ; Mon, 05 May 2014 12:53:19 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.221.8 with SMTP id qa8mr17376151wic.39.1399319599626; Mon, 05 May 2014 12:53:19 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 5 May 2014 12:53:19 -0700 (PDT) In-Reply-To: <335B84BDA2818C428E63D9B0ADE6863545AF7A1A@szxeml561-mbx.china.huawei.com> References: <335B84BDA2818C428E63D9B0ADE6863545AF7228@szxeml561-mbx.china.huawei.com> <335B84BDA2818C428E63D9B0ADE6863545AF7A1A@szxeml561-mbx.china.huawei.com> Date: Mon, 5 May 2014 14:53:19 -0500 Message-ID: From: Nico Williams To: Syed Ajim Hussain Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/b0KNlyR-PkcNIIDZJynqU0_4P6Q Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] Simultaneous Child SA Creation tigger from both the side. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 19:53:26 -0000 On Sun, May 4, 2014 at 11:53 PM, Syed Ajim Hussain wrote: > Thanks for your reply, This problem happened in real scenario, problem is- both the Tunnel end points are different vendor, > They handle it differently. Near as I can tell there are two possible behaviors: two (or more) sets of SAs, or one set with each exchange resulting in new SAs that replace the old ones. If other behaviors result, I'd like to hear it! > We can defined this behavior in RFC, If the two behaviors result straightforwardly from the RFC as it stands and local implementation choices, then I don't see a need to "define", just describe. Publishing a new RFC to describe this seems a bit wasteful of resources. Nico -- From nobody Mon May 5 12:56:48 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719E81A047B for ; Mon, 5 May 2014 12:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FegilP0IvXlm for ; Mon, 5 May 2014 12:56:45 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E50211A0469 for ; Mon, 5 May 2014 12:56:45 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 5C9912007EE06 for ; Mon, 5 May 2014 12:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=+bNJYtBTqDPWzqZBMboj QPHsKs8=; b=MKThiRTC5Inyf3Tqgw2UVwOwzwgypIRD1l1m7hr7No65UbVtjtUu pg6haw0X2jYaCNpKWMCjag+/2IRJJ2XzI2GlXf4zjnE3xZ6okT7dF0HuMZQ3V7Kl hsvBzHf7ue0Wk/U9w8SMB/7j3je5C4WP9K/t730HSwirbZ0GDjL3l94= Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPSA id 10E4E2007EE04 for ; Mon, 5 May 2014 12:56:41 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id bs8so3230585wib.3 for ; Mon, 05 May 2014 12:56:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.77.225 with SMTP id v1mr969684wiw.5.1399319800616; Mon, 05 May 2014 12:56:40 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 5 May 2014 12:56:40 -0700 (PDT) In-Reply-To: References: <335B84BDA2818C428E63D9B0ADE6863545AF7228@szxeml561-mbx.china.huawei.com> <335B84BDA2818C428E63D9B0ADE6863545AF7A1A@szxeml561-mbx.china.huawei.com> Date: Mon, 5 May 2014 14:56:40 -0500 Message-ID: From: Nico Williams To: Syed Ajim Hussain Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Cos_3UbHU2TNDiHFfkCla4SFTd0 Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] Simultaneous Child SA Creation tigger from both the side. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 19:56:46 -0000 Also, it seems clear that any implementation that adheres to the spec as it is will either a) produce just one set of SAs in this case (see Paul's response), or b) propose N>=1 sets of SAs. The (b) case should interop with the (a) case just fine, resulting in N==1 set of SAs. All three possible combinations of implementation behaviors should interop. Nico -- From nobody Mon May 5 13:49:35 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34091A0636 for ; Mon, 5 May 2014 13:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDgGC9x7todL for ; Mon, 5 May 2014 13:49:31 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id A01801A0549 for ; Mon, 5 May 2014 13:49:31 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id l18so7168869wgh.35 for ; Mon, 05 May 2014 13:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3LkpR80rtA2vz1O4MmANBANE7sfa4hD2pHKmygYGS1U=; b=r95kc/xR278b/ApUmD//6Ou34kAVQLnckPQy0fme2Jdj1Ix4T8YqPBIJ0FEne8+SfY FfHoGqZl7UIre2H4jVH0toMAwAPWEOd5pHfML5fqyS4MVjB8PUvCUKGMkLkhye+5eZw1 sfiKRq2vxJlAduzz9OtwtsevTgk2m7LdvqppSn9HZRLFnqtpn7j/gZ9y7ysRfPoYWuuA yCRyk/7P4IcmAnDU3gERONaB8d6igI1H+jy4mZkrDmmGLjLQybFurrripyvwiNOwEcUm r7mHPanPLGRbzWv2nuASHbQZqfHsOmNwMzSOBbpMgR9eFt+fqmVhk7uWJoa01S+NWFqJ tV+A== X-Received: by 10.194.71.164 with SMTP id w4mr29655779wju.0.1399322967545; Mon, 05 May 2014 13:49:27 -0700 (PDT) Received: from [192.168.1.102] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id hr4sm5012049wjb.28.2014.05.05.13.49.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 May 2014 13:49:26 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: Date: Mon, 5 May 2014 23:49:24 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1D7D673B-B8E1-4070-BC2C-CDA06EFB6387@gmail.com> References: <335B84BDA2818C428E63D9B0ADE6863545AF7228@szxeml561-mbx.china.huawei.com> <335B84BDA2818C428E63D9B0ADE6863545AF7A1A@szxeml561-mbx.china.huawei.com> To: Nico Williams X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/hz2K4PB0NYfHeYUiI9xQCUg_UKg Cc: "ipsec@ietf.org" , Syed Ajim Hussain Subject: Re: [IPsec] Simultaneous Child SA Creation tigger from both the side. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 20:49:33 -0000 The premise is that the implementation supports just one set of SAs. So both send out a request, and both receive the other request first, = and then the response to their respective original request. If both = peers now send out a DELETE to remove the SA initiated by the other = side, they will end up with no SAs at all. =20 That may be interop, but it=92s not a good result. Yoav On May 5, 2014, at 10:56 PM, Nico Williams = wrote: > Also, it seems clear that any implementation that adheres to the spec > as it is will either a) produce just one set of SAs in this case (see > Paul's response), or b) propose N>=3D1 sets of SAs. The (b) case = should > interop with the (a) case just fine, resulting in N=3D=3D1 set of SAs. > All three possible combinations of implementation behaviors should > interop. >=20 > Nico > -- From nobody Mon May 5 13:51:20 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCD61A0643 for ; Mon, 5 May 2014 13:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLEfPDgh4s2f for ; Mon, 5 May 2014 13:51:15 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 81F4D1A0640 for ; Mon, 5 May 2014 13:51:15 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id gl10so954435lab.16 for ; Mon, 05 May 2014 13:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8Zwcx/v89DB9J/KBDGd0MZZCExuyE3CADvz0SyLYm6I=; b=nWT/Jxn+ggYAtTtDkt7IlFnWQ7r9w0vBQhFmXbQlm/h/65BGILqIjXnO0CmLkxMhau rvSV8dOfHNmS5VKtf7TcRcXhxM4e/YcVjob82tVoeX5BTYUAX5P+Mb0tWt+ELETe0QHs wTNLh9p4MjkAinwx4SyUAK5vdv1nzPNRTT0jXqfsfanw2MDZWjgsYG8yFQGEnsXntkpr l4xZsXjQ26gS3anY9kKJ+ml9ClEUcVN9IfmMjjyXLDm1ZU+iM/avA7J3gW44z7yCeKVV mgX28f8dXMH3UNf8jp6wnhwxZ3gYBHzQzLUQDcL4uGhgk3+dwJB6HFkwdHlWr9HNk7NQ gzuQ== X-Received: by 10.112.12.103 with SMTP id x7mr3551768lbb.36.1399323071310; Mon, 05 May 2014 13:51:11 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:d5a4:211a:a8ec:b8ab? ([2001:1bc8:101:f101:d5a4:211a:a8ec:b8ab]) by mx.google.com with ESMTPSA id x5sm10769206lbk.5.2014.05.05.13.51.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 May 2014 13:51:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Jouni In-Reply-To: Date: Mon, 5 May 2014 23:51:08 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <68C598E1-9409-4ED1-8907-4C9ECC34A03E@gmail.com> References: <357CC5D9-48D2-4E4E-BB2F-5F002FF824C8@gmail.com> To: Ahmad Muhanna X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/bnz8ykYBaJisYdr0DK3C0rdNFmk Cc: "ipsec@ietf.org" , "kilian.weniger@googlemail.com" , Vijay Kumar , vijay kn Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 20:51:18 -0000 Ahmad, I could be wrong but MOBIKE should technically allow the responder (SeGW = here) to update the addresses in the IPsec SA. At least that is how I = interpret the text in RFC4555 Section 3.5. Currently that is restricted = to a single specific scenario, though (and this to work, would require = SeGWs be able to share required SA information between each other using = some mechanism). - Jouni On May 5, 2014, at 7:29 PM, Ahmad Muhanna wrote: > Hello Jouni, >=20 > If my understanding is correct, MOBIKE allows the client to move its = IKE tunnel from one SeGW to another based on Handover, for example. A = multihoming IKE, if I may say. > What Vijay is trying to address (at least this is my understanding) = here is the scenario from the other end. When the SeGW is overloaded and = would like to REDIRECT the client to another SeGW. The client won't know = the condition at the SeGW and the SeGW is the one who initiates the = proposed move. >=20 > Regards, > Ahmad >=20 >=20 >=20 > On Mon, May 5, 2014 at 9:03 AM, Jouni wrote: >=20 > Just a thought.. would MOBIKE be any use here? At least one would be = able to move the SeGWs on fly (assuming the source and destination SeGW = are able to share required information between each other). >=20 > - Jouni >=20 > On May 5, 2014, at 3:45 PM, Ahmad Muhanna wrote: >=20 > > Hi Vijay, > > > > Please see comments inline. > > > > On Mon, May 5, 2014 at 12:30 AM, vijay kn = wrote: > > Hi Ahmad, > > > > If you meant re-negotiating is IKEv2 rekey then it will not work = because IKEv2 rekey will not send any IKE_SA_INIT packet. As of now, the = RFC says that REDIRECT_SUPPORTED payload can be sent only in IKE_SA_INIT = msg. > > > > OR > > > > If you meant re-negotiating is completely delete the current SA and = re-negotiate the SA from scratch, this would lead to service loss/pkt = loss. > > > > > > > > [Ahmad] > > Yes. I meant the later. > > > > If we look at all scenarios that could be applicable to what you are = trying to solve, one end of the IKE SA needs to be upgraded to support = REDIRECTION. In my experience, that always happens in a controlled = environment (i.e., a maintenance window). In addition, operators do this = kind of activity very carefully and NOT globally; meaning, they upgrade = a limited number of nodes at a time or during a specific period. > > > > The fact that the client and the SeGW -OR- the peers are from = different vendors or even in different operator domains for the sake of = making this more complex, it is always the case that when a new = functionality is introduced, there is an expectation of service = interruption. > > > > NOW: even if we allow this feature as part of this RFC, there is = still no guarantee for the functionality to be successfully negotiated = using the proposed solution. Because that will introduce another level = of complexity and other backward compatibility scenarios that need to be = considered when one of the peers support this functionality and the = other does not. > > > > For example: what about if the SeGW support REDIRECTION as per = RFC5685 but NOT by the newly introduced functionality (assuming that has = been adopted). Although, the SeGW support REDIRECTION, but it would NOT = be able to recognize and support this functionality. This means that it = wont work but renegotiation of the IKE SA will still work. > > > > IMO, what you are trying to do is a completely new feature that is = not in the scope of this RFC and that is why I said this RFC does not = need to be updated or changed. I believe what you are trying to do is = some kind of dynamic mechanism that allow one peer to check with the = other peer on what kind of functionality it supports vs. what it does = NOT support with some forward compatibility in mind. > > That is totally and completely different than this RFC and can be = applicable to many other scenarios and RFCs other than this one. > > > > I hope I am making sense. > > > > Regards, > > Ahmad > > > > > > Recommendation: - > > > > Since the base stations normally establish Tunnel with other vendor = base stations and/or other vendor Gateways which may or may not support = REDIRECT, it is better to add this solution (client to send a new INFO = msg with the REDIRECT_SUPPORTED notify payload) to enable a SMOOTH = inter-op with other vendor implementations. > > > > > > > > Because of these reasons, I feel the RFC needs correction. > > > > > > > > > > > > From: Ahmad Muhanna [mailto:asmuhanna@gmail.com] > > Sent: Sunday, May 04, 2014 9:41 PM > > To: vijay kn > > Cc: vijay@wichorus.com; kilian.weniger@googlemail.com; = ipsec@ietf.org; vjkumar2003@gmail.com > > Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC = 5685) > > > > > > > > Hi, Vijay, > > > > > > > > I am NOT one if the authors of this RFC but I recall the discussion = and the use case. If I understand the scenario correctly, the client in = this case (eNB) negotiated an IKE SA without indicating the ability to = support REDIRECT. If that is the case, the client should renegotiate IKE = SA after being upgraded to support this functionality. My understanding = renegotiating IKE SA is supported. > > > > > > > > IMO, I do not think that anything in this RFC needs to be changed. > > > > > > Regards, > > > > Ahmad Muhanna > > > > > > On May 2, 2014, at 9:14 AM, vijay kn wrote: > > > > Hi, > > > > There is an issue in IKEv2 REDIRECT RFC 5685. In one scenario, the = IKEv2 REDIRECT will not work indefinitely. > > > > > > > > Scenario: - > > > > Let=92s assume there are about 1000 clients connected to a IKEv2 = REDIRECT enabled SeGW. None of the clients were IKEv2 redirect enabled = at the time of establishing SA with the SeGW (meaning they have not sent = the REDIRECT_SUPPORTED notification in the > > > > IKE_SA_INIT message) > > > > This will lead to a situation where the SeGW is loaded and wanting = to redirect some clients to another SeGW but it cannot REDIRECT them as = none of them have indicated REDIRECT support in the IKE_SA_INIT message. > > > > If the user/operator enabled REDIRECT functionality dynamically = (like after SAs were established), then the SeGW is not going to = redirect them because it had not received a REDIRECT_SUPPORTED payload = from the clients. > > > > > > > > Effect/Impact: - > > > > This leads to a congestion/overload at the gateway when the base = stations connecting to the SeGW are several hundred/thousands in number. = In the LTE and LTE-A scenarios, this condition is possible where the = number of base stations connecting to the SeGW are very high. > > > > > > > > Suggestion/Solution: - > > > > A change is required in RFC 5685 is required as below: - > > > > =93=94Whenever the redirect feature/functionality is enabled at = run-time, the client should indicate the same to the SeGW. This can be = done by the client sending an INFORMATIONAL message under the = protection of the IKE SA. This message MUST have a REDIRECT_SUPPORTED = notify payload to enable the SeGW to redirect them at run-time even = though they had initially connected with SeGW without REDIRECT support=94=94= > > > > > > > > Request for comments: - > > > > Please read the problem, impact and solution listed above and let me = know if any comments. Hope my point is valid and needs to be = incorporated as the RFC update. > > > > > > > > > > > > Regards, > > > > Vijay N. > > > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > -- > > Regards, > > Ahmad > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec >=20 >=20 >=20 >=20 > --=20 > Regards, > Ahmad From nobody Mon May 5 13:54:25 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B8D1A0640 for ; Mon, 5 May 2014 13:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fVb3U5IRxN2 for ; Mon, 5 May 2014 13:54:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id DBB231A064A for ; Mon, 5 May 2014 13:54:20 -0700 (PDT) Received: from CO2PR05MB665.namprd05.prod.outlook.com (10.141.230.11) by CO2PR05MB666.namprd05.prod.outlook.com (10.141.230.19) with Microsoft SMTP Server (TLS) id 15.0.929.12; Mon, 5 May 2014 20:54:16 +0000 Received: from CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) by CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) with mapi id 15.00.0929.001; Mon, 5 May 2014 20:54:16 +0000 From: Praveen Sathyanarayan To: Paul Wouters , Syed Ajim Hussain Thread-Topic: [IPsec] Simultaneous Child SA Creation tigger from both the side. Thread-Index: AQHPaKQso6QgWQM1tketdY4mgGHdpw== Date: Mon, 5 May 2014 20:54:15 +0000 Message-ID: References: <335B84BDA2818C428E63D9B0ADE6863545AF7228@szxeml561-mbx.china.huawei.com> <335B84BDA2818C428E63D9B0ADE6863545AF7A1A@szxeml561-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.239.10] x-forefront-prvs: 0202D21D2F x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(51704005)(52044002)(164054003)(189002)(199002)(479174003)(377454003)(92566001)(92726001)(15975445006)(20776003)(87936001)(99286001)(77982001)(2656002)(77096999)(83506001)(101416001)(46102001)(36756003)(99396002)(81342001)(85852003)(86362001)(31966008)(4396001)(54356999)(80022001)(74502001)(74662001)(83322001)(83072002)(81542001)(66066001)(76176999)(79102001)(76482001)(19580395003)(19580405001)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB666; H:CO2PR05MB665.namprd05.prod.outlook.com; FPR:7ED6F9B1.ACD014C5.F1D23B7A.48E5DFF3.202D6; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <7164F07A1E2F48469F6147A63CB42D9D@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/9ufOjOpp5g2Uvc50tk0aFjLgjVg Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] Simultaneous Child SA Creation tigger from both the side. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 20:54:23 -0000 I agree, it is a corner case. Example, out of 5000 tunnels, may be we will see 10 to 15 tunnels end up in this scenario. So memory/resource is not a concern. But question is, how do we handle once we are in that state. For example, which phase1/phase2 SA we should continue to hold (Rekey) and which one we need drop it, etc. This is where the confusion comes. Each vendor may end up choosing different way to handle it and it may cause confusion with other vendor. If there is a clear description on how to handle (which one to choose and which one to drop), will help. Thanks, Praveen On 5/5/14, 6:09 AM, "Paul Wouters" wrote: On Mon, 5 May 2014, Syed Ajim Hussain wrote: > Thanks for your reply, This problem happened in real scenario, >problem is- both the Tunnel end points are different vendor, > They handle it differently. > > We can defined this behavior in RFC, > > Also we have some other scenarios, it will be better if we define >these extreme case behavior also in RFC, > to make inter-op smooth. In libreswan (openswan) the daemon processes one packet at a time, so by definition one of the child SA's finishes before the other, no matter how close the timing is. It also has a feature "uniqueids" that would (dis)allow identical Child SA's, so the latter one establishing replaces the previous one established. I'm not convinced your issue is a protocol issue. It seems more like an implementation issue? If any of your endpoints involved libreswan/openswan, feel free to contact me. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon May 5 15:17:49 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6DE1A01A6 for ; Mon, 5 May 2014 15:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imdIUbC4ZJt2 for ; Mon, 5 May 2014 15:17:39 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE851A0195 for ; Mon, 5 May 2014 15:17:38 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id r5so1741324qcx.7 for ; Mon, 05 May 2014 15:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OX3NlQbcQzV+rwyv0+ib3igbiGmELDKdwfzMDNXRyuw=; b=IPQDfGzWXAKpfX+qLrk1zgCR4H6OR5yac2bAXueDn6/KdBWto+3ROeLPCH3U5MzQPa OtkO/a3BZ3F9taT7gaofKg5w/QAy4DPfQX2K43yZzHjI2EWMd3S3PjTLTA5SxCykonw9 v5kSV4DUxX0Bwh+Z1PFPGEnZDB4RlIbMdxz9NJjclA08cEvZFnrWyCedbx0KrZkSEAPs 6711AhpV5UsKoha9XdyYs5u1L+S6PKV+bjmwsfokxPH12cb+n2TG2WEJu1UzbgeZHIM3 nRAiqQR2RV8DQ3CjQVXLg/1bnNApDH0R0j2GRZIjLi5+G+UPbUhT1qMZefogUKuANCnl wPoQ== MIME-Version: 1.0 X-Received: by 10.140.108.4 with SMTP id i4mr46147476qgf.80.1399328255331; Mon, 05 May 2014 15:17:35 -0700 (PDT) Received: by 10.140.84.7 with HTTP; Mon, 5 May 2014 15:17:35 -0700 (PDT) In-Reply-To: <68C598E1-9409-4ED1-8907-4C9ECC34A03E@gmail.com> References: <357CC5D9-48D2-4E4E-BB2F-5F002FF824C8@gmail.com> <68C598E1-9409-4ED1-8907-4C9ECC34A03E@gmail.com> Date: Mon, 5 May 2014 17:17:35 -0500 Message-ID: From: Ahmad Muhanna To: Jouni Content-Type: multipart/alternative; boundary=001a1139573e9554f104f8ae7f7d Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/hXQ-i4kUCNFFgOlbFdqVdquUNrY Cc: "ipsec@ietf.org" , "kilian.weniger@googlemail.com" , Vijay Kumar , vijay kn Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 22:17:43 -0000 --001a1139573e9554f104f8ae7f7d Content-Type: text/plain; charset=ISO-8859-1 Hello Jouni, I see what you are saying but that is still a stretch :) As per section 3.5, the following is the relative text: There is one exception to the rule that the responder never updates any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request. If the source address that the responder is currently using becomes unavailable (i.e., sending packets using that source address is no longer possible), the responder is allowed to update the IPsec SAs to use some other address (in addition to initiating the procedure described in the next section). I guess this text is very powerful and at the same time what we have currently is a little different than the IP address of the SeGW becoming unavailable. At any rate: IMO, I believe that Re-authentication as listed in RFC5996 and as pointed out by Praveen is the correct approach. Regards, Ahmad On Mon, May 5, 2014 at 3:51 PM, Jouni wrote: > > Ahmad, > > I could be wrong but MOBIKE should technically allow the responder (SeGW > here) to update the addresses in the IPsec SA. At least that is how I > interpret the text in RFC4555 Section 3.5. Currently that is restricted to > a single specific scenario, though (and this to work, would require SeGWs > be able to share required SA information between each other using some > mechanism). > > - Jouni > > On May 5, 2014, at 7:29 PM, Ahmad Muhanna wrote: > > > Hello Jouni, > > > > If my understanding is correct, MOBIKE allows the client to move its IKE > tunnel from one SeGW to another based on Handover, for example. A > multihoming IKE, if I may say. > > What Vijay is trying to address (at least this is my understanding) here > is the scenario from the other end. When the SeGW is overloaded and would > like to REDIRECT the client to another SeGW. The client won't know the > condition at the SeGW and the SeGW is the one who initiates the proposed > move. > > > > Regards, > > Ahmad > > > > > > > > On Mon, May 5, 2014 at 9:03 AM, Jouni wrote: > > > > Just a thought.. would MOBIKE be any use here? At least one would be > able to move the SeGWs on fly (assuming the source and destination SeGW are > able to share required information between each other). > > > > - Jouni > > > > On May 5, 2014, at 3:45 PM, Ahmad Muhanna wrote: > > > > > Hi Vijay, > > > > > > Please see comments inline. > > > > > > On Mon, May 5, 2014 at 12:30 AM, vijay kn wrote: > > > Hi Ahmad, > > > > > > If you meant re-negotiating is IKEv2 rekey then it will not work > because IKEv2 rekey will not send any IKE_SA_INIT packet. As of now, the > RFC says that REDIRECT_SUPPORTED payload can be sent only in IKE_SA_INIT > msg. > > > > > > OR > > > > > > If you meant re-negotiating is completely delete the current SA and > re-negotiate the SA from scratch, this would lead to service loss/pkt loss. > > > > > > > > > > > > [Ahmad] > > > Yes. I meant the later. > > > > > > If we look at all scenarios that could be applicable to what you are > trying to solve, one end of the IKE SA needs to be upgraded to support > REDIRECTION. In my experience, that always happens in a controlled > environment (i.e., a maintenance window). In addition, operators do this > kind of activity very carefully and NOT globally; meaning, they upgrade a > limited number of nodes at a time or during a specific period. > > > > > > The fact that the client and the SeGW -OR- the peers are from > different vendors or even in different operator domains for the sake of > making this more complex, it is always the case that when a new > functionality is introduced, there is an expectation of service > interruption. > > > > > > NOW: even if we allow this feature as part of this RFC, there is still > no guarantee for the functionality to be successfully negotiated using the > proposed solution. Because that will introduce another level of complexity > and other backward compatibility scenarios that need to be considered when > one of the peers support this functionality and the other does not. > > > > > > For example: what about if the SeGW support REDIRECTION as per RFC5685 > but NOT by the newly introduced functionality (assuming that has been > adopted). Although, the SeGW support REDIRECTION, but it would NOT be able > to recognize and support this functionality. This means that it wont work > but renegotiation of the IKE SA will still work. > > > > > > IMO, what you are trying to do is a completely new feature that is not > in the scope of this RFC and that is why I said this RFC does not need to > be updated or changed. I believe what you are trying to do is some kind of > dynamic mechanism that allow one peer to check with the other peer on what > kind of functionality it supports vs. what it does NOT support with some > forward compatibility in mind. > > > That is totally and completely different than this RFC and can be > applicable to many other scenarios and RFCs other than this one. > > > > > > I hope I am making sense. > > > > > > Regards, > > > Ahmad > > > > > > > > > Recommendation: - > > > > > > Since the base stations normally establish Tunnel with other vendor > base stations and/or other vendor Gateways which may or may not support > REDIRECT, it is better to add this solution (client to send a new INFO msg > with the REDIRECT_SUPPORTED notify payload) to enable a SMOOTH inter-op > with other vendor implementations. > > > > > > > > > > > > Because of these reasons, I feel the RFC needs correction. > > > > > > > > > > > > > > > > > > From: Ahmad Muhanna [mailto:asmuhanna@gmail.com] > > > Sent: Sunday, May 04, 2014 9:41 PM > > > To: vijay kn > > > Cc: vijay@wichorus.com; kilian.weniger@googlemail.com; ipsec@ietf.org; > vjkumar2003@gmail.com > > > Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC > 5685) > > > > > > > > > > > > Hi, Vijay, > > > > > > > > > > > > I am NOT one if the authors of this RFC but I recall the discussion > and the use case. If I understand the scenario correctly, the client in > this case (eNB) negotiated an IKE SA without indicating the ability to > support REDIRECT. If that is the case, the client should renegotiate IKE SA > after being upgraded to support this functionality. My understanding > renegotiating IKE SA is supported. > > > > > > > > > > > > IMO, I do not think that anything in this RFC needs to be changed. > > > > > > > > > Regards, > > > > > > Ahmad Muhanna > > > > > > > > > On May 2, 2014, at 9:14 AM, vijay kn wrote: > > > > > > Hi, > > > > > > There is an issue in IKEv2 REDIRECT RFC 5685. In one scenario, the > IKEv2 REDIRECT will not work indefinitely. > > > > > > > > > > > > Scenario: - > > > > > > Let's assume there are about 1000 clients connected to a IKEv2 > REDIRECT enabled SeGW. None of the clients were IKEv2 redirect enabled at > the time of establishing SA with the SeGW (meaning they have not sent the > REDIRECT_SUPPORTED notification in the > > > > > > IKE_SA_INIT message) > > > > > > This will lead to a situation where the SeGW is loaded and wanting to > redirect some clients to another SeGW but it cannot REDIRECT them as none > of them have indicated REDIRECT support in the IKE_SA_INIT message. > > > > > > If the user/operator enabled REDIRECT functionality dynamically (like > after SAs were established), then the SeGW is not going to redirect them > because it had not received a REDIRECT_SUPPORTED payload from the clients. > > > > > > > > > > > > Effect/Impact: - > > > > > > This leads to a congestion/overload at the gateway when the base > stations connecting to the SeGW are several hundred/thousands in number. In > the LTE and LTE-A scenarios, this condition is possible where the number of > base stations connecting to the SeGW are very high. > > > > > > > > > > > > Suggestion/Solution: - > > > > > > A change is required in RFC 5685 is required as below: - > > > > > > ""Whenever the redirect feature/functionality is enabled at run-time, > the client should indicate the same to the SeGW. This can be done by the > client sending an INFORMATIONAL message under the protection of the IKE > SA. This message MUST have a REDIRECT_SUPPORTED notify payload to enable > the SeGW to redirect them at run-time even though they had initially > connected with SeGW without REDIRECT support"" > > > > > > > > > > > > Request for comments: - > > > > > > Please read the problem, impact and solution listed above and let me > know if any comments. Hope my point is valid and needs to be incorporated > as the RFC update. > > > > > > > > > > > > > > > > > > Regards, > > > > > > Vijay N. > > > > > > > > > > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > > > > > > -- > > > Regards, > > > Ahmad > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > -- > > Regards, > > Ahmad > > -- Regards, Ahmad --001a1139573e9554f104f8ae7f7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Jouni,

I see what you are saying = but that is still a stretch :)
As per section 3.5, the following = is the relative text:
   There is one exception to the rule =
that the responder never updates
   any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request.  If
   the source address that the responder is currently using becomes
   unavailable (i.e., sending packets using that source address is no
   longer possible), the responder is allowed to update the IPsec SAs to
   use some other address (in addition to initiating the procedure
   described in the next section).
I guess this text is very powe=
rful and at the same time what we have currently is a little different than=
 the IP address of the SeGW becoming unavailable.
At any rate: IM=
O, I believe that Re-authentication as listed in RFC5996 and as pointed out=
 by Praveen is the correct approach.
Regards,
Ahmad



On Mon, May 5, 2014 at 3:51 PM, Jouni <<= a href=3D"mailto:jouni.nospam@gmail.com" target=3D"_blank">jouni.nospam@gma= il.com> wrote:

Ahmad,

I could be wrong but MOBIKE should technically allow the responder (SeGW he= re) to update the addresses in the IPsec SA. At least that is how I interpr= et the text in RFC4555 Section 3.5. Currently that is restricted to a singl= e specific scenario, though (and this to work, would require SeGWs be able = to share required SA information between each other using some mechanism).<= br>
- Jouni

On May 5, 2014, at 7:29 PM, Ahmad Muhanna wrote:

> Hello Jouni,
>
> If my understanding is correct, MOBIKE allows the client to move its I= KE tunnel from one SeGW to another based on Handover, for example. A multih= oming IKE, if I may say.
> What Vijay is trying to address (at least this is my understanding) he= re is the scenario from the other end. When the SeGW is overloaded and woul= d like to REDIRECT the client to another SeGW. The client won't know th= e condition at the SeGW and the SeGW is the one who initiates the proposed = move.
>
> Regards,
> Ahmad
>
>
>
> On Mon, May 5, 2014 at 9:03 AM, Jouni <jouni.nospam@gmail.com> wrote:
>
> Just a thought.. would MOBIKE be any use here? At least one would be a= ble to move the SeGWs on fly (assuming the source and destination SeGW are = able to share required information between each other).
>
> - Jouni
>
> On May 5, 2014, at 3:45 PM, Ahmad Muhanna wrote:
>
> > Hi Vijay,
> >
> > Please see comments inline.
> >
> > On Mon, May 5, 2014 at 12:30 AM, vijay kn <vijay.kn@huawei.com> wrote:
> > Hi Ahmad,
> >
> > If you meant re-negotiating is IKEv2 rekey then it will not work = because IKEv2 rekey will not send any IKE_SA_INIT packet. As of now, the RF= C says that REDIRECT_SUPPORTED payload can be sent only in IKE_SA_INIT msg.=
> >
> > OR
> >
> > If you meant re-negotiating is completely delete the current SA a= nd re-negotiate the SA from scratch, this would lead to service loss/pkt lo= ss.
> >
> >
> >
> > [Ahmad]
> > Yes. I meant the later.
> >
> > If we look at all scenarios that could be applicable to what you = are trying to solve, one end of the IKE SA needs to be upgraded to support = REDIRECTION. In my experience, that always happens in a controlled environm= ent (i.e., a maintenance window). In addition, operators do this kind of ac= tivity very carefully and NOT globally; meaning, they upgrade a limited num= ber of nodes at a time or during a specific period.
> >
> > The fact that the client and the SeGW -OR- the peers are from dif= ferent vendors or even in different operator domains for the sake of making= this more complex, it is always the case that when a new functionality is = introduced, there is an expectation of service interruption.
> >
> > NOW: even if we allow this feature as part of this RFC, there is = still no guarantee for the functionality to be successfully negotiated usin= g the proposed solution. Because that will introduce another level of compl= exity and other backward compatibility scenarios that need to be considered= when one of the peers support this functionality and the other does not. > >
> > For example: what about if the SeGW support REDIRECTION as per RF= C5685 but NOT by the newly introduced functionality (assuming that has been= adopted). Although, the SeGW support REDIRECTION, but it would NOT be able= to recognize and support this functionality. This means that it wont work = but renegotiation of the IKE SA will still work.
> >
> > IMO, what you are trying to do is a completely new feature that i= s not in the scope of this RFC and that is why I said this RFC does not nee= d to be updated or changed. I believe what you are trying to do is some kin= d of dynamic mechanism that allow one peer to check with the other peer on = what kind of functionality it supports vs. what it does NOT support with so= me forward compatibility in mind.
> > That is totally and completely different than this RFC and can be= applicable to many other scenarios and RFCs other than this one.
> >
> > I hope I am making sense.
> >
> > Regards,
> > Ahmad
> >
> >
> > Recommendation: -
> >
> > Since the base stations normally establish Tunnel with other vend= or base stations and/or other vendor Gateways which may or may not support =  REDIRECT, it is better to add this solution (client to send a new INF= O msg with the REDIRECT_SUPPORTED notify payload) to enable a SMOOTH inter-= op with other vendor implementations.
> >
> >
> >
> > Because of these reasons, I feel the RFC needs correction.
> >
> >
> >
> >
> >
> > From: Ahmad Muhanna [mailto:asmuhanna@gmail.com]
> > Sent: Sunday, May 04, 2014 9:41 PM
> > To: vijay kn
> > Cc: vijay@wichorus.com;= kilian.weniger@googlemail= .com; ipsec@ietf.org; vjkumar2003@gmail.com
> > Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference = RFC 5685)
> >
> >
> >
> > Hi, Vijay,
> >
> >
> >
> > I am NOT one if the authors of this RFC but I recall the discussi= on and the use case. If I understand the scenario correctly, the client in = this case (eNB) negotiated an IKE SA without indicating the ability to supp= ort REDIRECT. If that is the case, the client should renegotiate IKE SA aft= er being upgraded to support this functionality. My understanding renegotia= ting IKE SA is supported.
> >
> >
> >
> > IMO, I do not think that anything in this RFC needs to be changed= .
> >
> >
> > Regards,
> >
> > Ahmad Muhanna
> >
> >
> > On May 2, 2014, at 9:14 AM, vijay kn <vijay.kn@huawei.com> wrote:
> >
> > Hi,
> >
> > There is an issue in IKEv2 REDIRECT RFC 5685. In one scenario, th= e IKEv2 REDIRECT will not work indefinitely.
> >
> >
> >
> > Scenario: -
> >
> > Let’s assume there are about 1000 clients connected to a IK= Ev2 REDIRECT enabled SeGW. None of the clients were IKEv2 redirect enabled = at the time of establishing SA with the SeGW (meaning they have not sent th= e REDIRECT_SUPPORTED notification in the
> >
> > IKE_SA_INIT message)
> >
> > This will lead to a situation where the SeGW is loaded and wantin= g to redirect some clients to another SeGW but it cannot REDIRECT them as n= one of them have indicated REDIRECT support in the IKE_SA_INIT message.
> >
> > If the user/operator enabled REDIRECT functionality dynamically (= like after SAs were established), then the SeGW is not going to redirect th= em because it had not received a REDIRECT_SUPPORTED payload from the client= s.
> >
> >
> >
> > Effect/Impact: -
> >
> > This leads to a congestion/overload at the gateway when the base = stations connecting to the SeGW are several hundred/thousands in number. In= the LTE and LTE-A scenarios, this condition is possible where the number o= f base stations connecting to the SeGW are very high.
> >
> >
> >
> > Suggestion/Solution: -
> >
> > A change is required in RFC 5685 is required as below: -
> >
> > “”Whenever the redirect feature/functionality is enab= led at run-time, the client should indicate the same to the SeGW. This can = be done by the client sending an INFORMATIONAL message  under the prot= ection of the IKE SA. This message MUST have a REDIRECT_SUPPORTED notify pa= yload to enable the SeGW to redirect them at run-time even though they had = initially connected with SeGW without REDIRECT support””
> >
> >
> >
> > Request for comments: -
> >
> > Please read the problem, impact and solution listed above and let= me know if any comments. Hope my point is valid and needs to be incorporat= ed as the RFC update.
> >
> >
> >
> >
> >
> > Regards,
> >
> > Vijay N.
> >
> >
> >
> > _______________________________________________
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
> >
> >
> >
> > --
> > Regards,
> > Ahmad
> > _______________________________________________
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
>
>
>
>
> --
> Regards,
> Ahmad




--
Regards,
Ahmad
--001a1139573e9554f104f8ae7f7d-- From nobody Mon May 5 20:45:58 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8561A06C4 for ; Mon, 5 May 2014 20:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljjAje2pJPCI for ; Mon, 5 May 2014 20:45:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 304EC1A06C1 for ; Mon, 5 May 2014 20:45:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDV95816; Tue, 06 May 2014 03:45:46 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 6 May 2014 04:44:29 +0100 Received: from SZXEML448-HUB.china.huawei.com (10.82.67.191) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 6 May 2014 04:45:43 +0100 Received: from SZXEML513-MBX.china.huawei.com ([169.254.7.157]) by szxeml448-hub.china.huawei.com ([10.82.67.191]) with mapi id 14.03.0158.001; Tue, 6 May 2014 11:45:37 +0800 From: vijay kn To: Ahmad Muhanna , Praveen Sathyanarayan Thread-Topic: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) Thread-Index: Ac9mCR4Wj8NaQqRJSGu1iyUmq2WiKQAB4oDwAFfs6YAALHiKIAAHvc2AAABsCQAAJpwJQA== Date: Tue, 6 May 2014 03:45:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.146.58] Content-Type: multipart/alternative; boundary="_000_AD5AD8B0B070044BAD3C37D7057F37E153FE65DBszxeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/MspBNAT8mP1z-fMDozbRLUeQF3o Cc: "ipsec@ietf.org" , "vijay@wichorus.com" , "kilian.weniger@googlemail.com" , "vjkumar2003@gmail.com" Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 03:45:55 -0000 --_000_AD5AD8B0B070044BAD3C37D7057F37E153FE65DBszxeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Praveen/Ahmad, Some vendors don't support Reauth. In this case what to do? I think we are slightly deviating from our original topic. Why to do reauth which is an expensive operation when you can just intimate= the SeGW that u support redirect via an INFO msg. Thanks. From: Ahmad Muhanna [mailto:asmuhanna@gmail.com] Sent: Monday, May 05, 2014 10:48 PM To: Praveen Sathyanarayan Cc: vijay kn; ipsec@ietf.org; vijay@wichorus.com; kilian.weniger@googlemail= .com; vjkumar2003@gmail.com Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) Thanks Praveen for pointing that out. That what I initially had in mind but got distracted by the notion that it = may cause service disruption without double checking RFC5996. I believe Re-authentication is the solution for this issue without causing = any service disruption. Although, service disruption is imminent in case of= upgrade anyway. Regards, Ahmad On Mon, May 5, 2014 at 12:05 PM, Praveen Sathyanarayan > wrote: Why not trigger Re-authentication from base station, when upgraded/REDIRECT= enabled in config? RFC 5996: Reauthentication is done by creating a new IKE SA from scratch (using IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA Notify payloads), creating new Child SAs within the new IKE SA (without REKEY_SA Notify payloads), and finally deleting the old IKE SA (which deletes the old Child SAs as well). Thanks, Praveen From: vijay kn > Date: Sunday, May 4, 2014 at 10:30 PM To: Ahmad Muhanna > Cc: "ipsec@ietf.org" >, "vijay@wichorus.com" >, "kilian.weniger@googlemail.com" >, "vjkumar2003@gmail.com= " > Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) Hi Ahmad, If you meant re-negotiating is IKEv2 rekey then it will not work because IK= Ev2 rekey will not send any IKE_SA_INIT packet. As of now, the RFC says tha= t REDIRECT_SUPPORTED payload can be sent only in IKE_SA_INIT msg. OR If you meant re-negotiating is completely delete the current SA and re-nego= tiate the SA from scratch, this would lead to service loss/pkt loss. Recommendation: - Since the base stations normally establish Tunnel with other vendor base st= ations and/or other vendor Gateways which may or may not support REDIRECT,= it is better to add this solution (client to send a new INFO msg with the = REDIRECT_SUPPORTED notify payload) to enable a SMOOTH inter-op with other v= endor implementations. Because of these reasons, I feel the RFC needs correction. From: Ahmad Muhanna [mailto:asmuhanna@gmail.com] Sent: Sunday, May 04, 2014 9:41 PM To: vijay kn Cc: vijay@wichorus.com; kilian.weniger@googlemai= l.com; ipsec@ietf.org; vjkumar2003@gmail.com Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) Hi, Vijay, I am NOT one if the authors of this RFC but I recall the discussion and the= use case. If I understand the scenario correctly, the client in this case = (eNB) negotiated an IKE SA without indicating the ability to support REDIRE= CT. If that is the case, the client should renegotiate IKE SA after being u= pgraded to support this functionality. My understanding renegotiating IKE S= A is supported. IMO, I do not think that anything in this RFC needs to be changed. Regards, Ahmad Muhanna On May 2, 2014, at 9:14 AM, vijay kn > wrote: Hi, There is an issue in IKEv2 REDIRECT RFC 5685. In one scenario, the IKEv2 RE= DIRECT will not work indefinitely. Scenario: - Let's assume there are about 1000 clients connected to a IKEv2 REDIRECT ena= bled SeGW. None of the clients were IKEv2 redirect enabled at the time of e= stablishing SA with the SeGW (meaning they have not sent the REDIRECT_SUPPO= RTED notification in the IKE_SA_INIT message) This will lead to a situation where the SeGW is loaded and wanting to redir= ect some clients to another SeGW but it cannot REDIRECT them as none of the= m have indicated REDIRECT support in the IKE_SA_INIT message. If the user/operator enabled REDIRECT functionality dynamically (like after= SAs were established), then the SeGW is not going to redirect them because= it had not received a REDIRECT_SUPPORTED payload from the clients. Effect/Impact: - This leads to a congestion/overload at the gateway when the base stations c= onnecting to the SeGW are several hundred/thousands in number. In the LTE a= nd LTE-A scenarios, this condition is possible where the number of base sta= tions connecting to the SeGW are very high. Suggestion/Solution: - A change is required in RFC 5685 is required as below: - ""Whenever the redirect feature/functionality is enabled at run-time, the c= lient should indicate the same to the SeGW. This can be done by the client = sending an INFORMATIONAL message under the protection of the IKE SA. This = message MUST have a REDIRECT_SUPPORTED notify payload to enable the SeGW to= redirect them at run-time even though they had initially connected with Se= GW without REDIRECT support"" Request for comments: - Please read the problem, impact and solution listed above and let me know i= f any comments. Hope my point is valid and needs to be incorporated as the = RFC update. Regards, Vijay N. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Regards, Ahmad --_000_AD5AD8B0B070044BAD3C37D7057F37E153FE65DBszxeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Praveen/Ahmad,=

Some vendors don’t = support Reauth. In this case what to do?

I think we are slightly d= eviating from our original topic.

Why to do reauth which is= an expensive operation when you can just intimate the SeGW that u support = redirect via an INFO msg.

 <= /p>

 <= /p>

Thanks.=

 <= /p>

From: Ahmad Mu= hanna [mailto:asmuhanna@gmail.com]
Sent: Monday, May 05, 2014 10:48 PM
To: Praveen Sathyanarayan
Cc: vijay kn; ipsec@ietf.org; vijay@wichorus.com; kilian.weniger@goo= glemail.com; vjkumar2003@gmail.com
Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC= 5685)

 

Thanks Praveen for pointing that out.

 

That what I initially had in mind but got distracted= by the notion that it may cause service disruption without double checking= RFC5996.

I believe Re-authentication is the solution for this= issue without causing any service disruption. Although, service disruption= is imminent in case of upgrade anyway.

 

Regards,

Ahmad

 

On Mon, May 5, 2014 at 12:05 PM, Praveen Sathyanaray= an <praveenys= @juniper.net> wrote:

Why not trigger Re-authentication from base = station, when upgraded/REDIRECT enabled in config?

 

RFC 5996:

 

   Reauthentica=
tion is done by creating a new IKE SA from scratch (using=

   IKE_SA_INIT/=
IKE_AUTH exchanges, without any REKEY_SA Notify
   payloads), c=
reating new Child SAs within the new IKE SA (without

   REKEY_SA Not=
ify payloads), and finally deleting the old IKE SA (which=



   deletes the =
old Child SAs as well).

 

Thanks,

Praveen

 

From: vijay kn <vijay.kn@huawei.com>
Date: Sunday, May 4, 2014 at 10:30 PM
To: Ahmad Muhanna <asmuhanna@gmail.com>
Cc: "ipsec@= ietf.org" <= ipsec@ietf.org>, "vijay@wichorus.com" <vijay@wichorus.com>, "k= ilian.weniger@googlemail.com" <kilian.weniger@googlemail.com>, &= quot;vjkumar2003= @gmail.com" <vjkumar2003= @gmail.com>
Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC= 5685)

 

Hi Ahmad,

If you meant re-negotiating is IKEv2= rekey then it will not work because IKEv2 rekey will not send any IKE_SA_I= NIT packet. As of now, the RFC says that REDIRECT_SUPPORTED payload can be sent only in IKE_SA_INIT msg.

OR

If you meant re-negotiating is compl= etely delete the current SA and re-negotiate the SA from scratch, this woul= d lead to service loss/pkt loss.

 

Recommendation: -

Since the base stations normally est= ablish Tunnel with other vendor base stations and/or other vendor Gateways = which may or may not support  REDIRECT, it is better to add this solution (client to send a new INFO msg with the = REDIRECT_SUPPORTED notify payload) to enable a SMOOTH inter-op with other v= endor implementations.=

 

Because of these reasons, I feel the= RFC needs correction.=

 

 

From: Ahmad Muhanna [mailto:a= smuhanna@gmail.com]
Sent: Sunday, May 04, 2014 9:41 PM
To: vijay kn
Cc: vijay@wi= chorus.com; kilian.w= eniger@googlemail.com; ipsec@ietf.org; vjkumar2003@gmail.com
Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC= 5685)

 

Hi, Vijay, 

 

I am NOT one if the authors of this RF= C but I recall the discussion and the use case. If I understand the scenari= o correctly, the client in this case (eNB) negotiated an IKE SA without indicating the ability to support REDIRECT. I= f that is the case, the client should renegotiate IKE SA after being upgrad= ed to support this functionality. My understanding renegotiating IKE SA is = supported.

 

IMO, I do not think that anything in t= his RFC needs to be changed.


Regards,

Ahmad Muhanna <= /p>


On May 2, 2014, at 9:14 AM, vijay kn <vijay.kn@huawei.com> wrote:=

Hi,

There is an issue in IKEv2 REDIRECT RFC 5685. In one scenario, the IKEv2 REDIRECT will not work ind= efinitely.

 

Scenario: -

Let’s assume there are about 100= 0 clients connected to a IKEv2 REDIRECT enabled SeGW. None of the clients were IKEv2 redirect enabled at the time of establish= ing SA with the SeGW (meaning they have not sent the REDIRECT_SUPPORTED= notification in the

IKE_SA_INIT message)=

This will lead to a situation where th= e SeGW is loaded and wanting to redirect some clients to another SeGW but i= t cannot REDIRECT them as none of them have indicated REDIRECT support in the IKE_SA_INIT message.

If the user/operator enabled REDIRECT = functionality dynamically (like after SAs were established), then the SeGW = is not going to redirect them because it had not received a REDIRECT_SUPPORTED payload from the clients.

 

Effect/Impact: -

This leads to a congestion/overload at= the gateway when the base stations connecting to the SeGW are several hund= red/thousands in number. In the LTE and LTE-A scenarios, this condition is possible where the number of base stati= ons connecting to the SeGW are very high.

 

Suggestion/Solution: -

A change is required in RFC 5685 is re= quired as below: -

“”Whenever the redirect = feature/functionality is enabled at run-time, the client should indicate th= e same to the SeGW. This can be done by the client sending an INFORMATIONAL message  under the protection of the IKE SA.= This message MUST have a REDIRECT_SUPPORTED notify payload to enable the S= eGW to redirect them at run-time even though they had initially connected w= ith SeGW without REDIRECT support””

 

Request for comments: -<= span style=3D"color:black">

Please read the problem, impact and so= lution listed above and let me know if any comments. Hope my point is valid= and needs to be incorporated as the RFC update.

 

 

Regards,

Vijay N.

 

______________________________________= _________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec



 

--

Regards,

Ahmad

--_000_AD5AD8B0B070044BAD3C37D7057F37E153FE65DBszxeml513mbxchi_-- From nobody Mon May 5 21:18:20 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2E91A0103 for ; Mon, 5 May 2014 21:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcHs_oW8AEcR for ; Mon, 5 May 2014 21:18:17 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id E724A1A0148 for ; Mon, 5 May 2014 21:18:16 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id y20so9199609ier.40 for ; Mon, 05 May 2014 21:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3BymQ/p+QZYZCb2NDTPN3ugs5Qo3z5Zzd2b/n6mjeAU=; b=UJ8ap0BV0fcAfsqBajbveUW8LEvaiq2yu5N2A1BNGXd7pqaZooPkXyWlyrt8eflMDI kLZaNUqlMpCudUSqawKbYMXcvekV/F2TtV+U+gXSJwgJUc6D35keaFLCbGasYybuhNx6 Mzac5ATz0TXY+U9Bv0f6xzwB1riP5OLF4YiycK7VwN+ydqhQDN2Bq8fZQDMTEBH/4fDi T6tzR//PYmvs+REHhs2QdhaIdg66F2rTeEkK9+fZlaxbKWkN8uMo7WNrrbxQK63h39wC cP6qY7ZqoSEunRlJ0kLz4XXKRvp+7j8BKSRXZf+H/clSzfNICvcA3IN9q0jmTPrrksVa S3Kg== X-Received: by 10.42.224.194 with SMTP id ip2mr63606icb.91.1399349893234; Mon, 05 May 2014 21:18:13 -0700 (PDT) Received: from [192.168.1.101] (adsl-99-30-174-168.dsl.sfldmi.sbcglobal.net. [99.30.174.168]) by mx.google.com with ESMTPSA id s1sm34286038igr.14.2014.05.05.21.18.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 May 2014 21:18:12 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-85229675-9519-429A-8243-EF359B70B9A9 Mime-Version: 1.0 (1.0) From: Ahmad Muhanna X-Mailer: iPhone Mail (11D201) In-Reply-To: Date: Mon, 5 May 2014 23:18:11 -0500 Content-Transfer-Encoding: 7bit Message-Id: <15950B41-4A0C-420C-819A-30F77790555E@gmail.com> References: To: vijay kn Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/g4roReRqdWsWtrwOZt32ILsFn_c Cc: "ipsec@ietf.org" , "vijay@wichorus.com" , "kilian.weniger@googlemail.com" , Praveen Sathyanarayan , "vjkumar2003@gmail.com" Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 04:18:19 -0000 --Apple-Mail-85229675-9519-429A-8243-EF359B70B9A9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Vijay, No one is trying to deviate from the original topic. Let me try to address w= hat you just mentioned one more time. You just mentioned that some vendors do not support Reauth. But let me remin= d you; no vendor is supporting what you are proposing now. How that becomes a= n argument. On the other hand, I provided you with an example that your proposal will NO= T solve; while the SeGW even support REDIRECTION as per RFC5685 already; you= some how chose to ignore it. Here is the text for the reminder: " For example: what about if the SeGW support REDIRECTION as per RFC5685 but N= OT by the newly introduced functionality (assuming that has been adopted). A= lthough, the SeGW support REDIRECTION, but it would NOT be able to recognize= and support this functionality. This means that it wont work but renegotiat= ion of the IKE SA will still work. " Regards, Ahmad > On May 5, 2014, at 10:45 PM, vijay kn wrote: >=20 > Praveen/Ahmad, > Some vendors don=E2=80=99t support Reauth. In this case what to do? > I think we are slightly deviating from our original topic. > Why to do reauth which is an expensive operation when you can just intimat= e the SeGW that u support redirect via an INFO msg. > =20 > =20 > Thanks. > =20 > From: Ahmad Muhanna [mailto:asmuhanna@gmail.com]=20 > Sent: Monday, May 05, 2014 10:48 PM > To: Praveen Sathyanarayan > Cc: vijay kn; ipsec@ietf.org; vijay@wichorus.com; kilian.weniger@googlemai= l.com; vjkumar2003@gmail.com > Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685)= > =20 > Thanks Praveen for pointing that out. > =20 > That what I initially had in mind but got distracted by the notion that it= may cause service disruption without double checking RFC5996. > I believe Re-authentication is the solution for this issue without causing= any service disruption. Although, service disruption is imminent in case of= upgrade anyway. > =20 > Regards, > Ahmad > =20 >=20 > On Mon, May 5, 2014 at 12:05 PM, Praveen Sathyanarayan wrote: > Why not trigger Re-authentication from base station, when upgraded/REDIREC= T enabled in config? > =20 > RFC 5996: > =20 > Reauthentication is done by creating a new IKE SA from scratch (using > IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA Notify > payloads), creating new Child SAs within the new IKE SA (without > REKEY_SA Notify payloads), and finally deleting the old IKE SA (which > deletes the old Child SAs as well). > =20 > Thanks, > Praveen > =20 > From: vijay kn > Date: Sunday, May 4, 2014 at 10:30 PM > To: Ahmad Muhanna > Cc: "ipsec@ietf.org" , "vijay@wichorus.com" , "kilian.weniger@googlemail.com" , "vj= kumar2003@gmail.com" > Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685)= > =20 > Hi Ahmad, > If you meant re-negotiating is IKEv2 rekey then it will not work because I= KEv2 rekey will not send any IKE_SA_INIT packet. As of now, the RFC says tha= t REDIRECT_SUPPORTED payload can be sent only in IKE_SA_INIT msg. > OR > If you meant re-negotiating is completely delete the current SA and re-neg= otiate the SA from scratch, this would lead to service loss/pkt loss. > =20 > Recommendation: - > Since the base stations normally establish Tunnel with other vendor base s= tations and/or other vendor Gateways which may or may not support REDIRECT,= it is better to add this solution (client to send a new INFO msg with the R= EDIRECT_SUPPORTED notify payload) to enable a SMOOTH inter-op with other ven= dor implementations. > =20 > Because of these reasons, I feel the RFC needs correction. > =20 > =20 > From: Ahmad Muhanna [mailto:asmuhanna@gmail.com]=20 > Sent: Sunday, May 04, 2014 9:41 PM > To: vijay kn > Cc: vijay@wichorus.com; kilian.weniger@googlemail.com; ipsec@ietf.org; vj= kumar2003@gmail.com > Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685)= > =20 > Hi, Vijay,=20 > =20 > I am NOT one if the authors of this RFC but I recall the discussion and th= e use case. If I understand the scenario correctly, the client in this case (= eNB) negotiated an IKE SA without indicating the ability to support REDIRECT= . If that is the case, the client should renegotiate IKE SA after being upgr= aded to support this functionality. My understanding renegotiating IKE SA is= supported. > =20 > IMO, I do not think that anything in this RFC needs to be changed. >=20 > Regards, > Ahmad Muhanna=20 >=20 > On May 2, 2014, at 9:14 AM, vijay kn wrote: >=20 > Hi, > There is an issue in IKEv2 REDIRECT RFC 5685. In one scenario, the IKEv2 R= EDIRECT will not work indefinitely. > =20 > Scenario: - > Let=E2=80=99s assume there are about 1000 clients connected to a IKEv2 RED= IRECT enabled SeGW. None of the clients were IKEv2 redirect enabled at the t= ime of establishing SA with the SeGW (meaning they have not sent the REDIREC= T_SUPPORTED notification in the > IKE_SA_INIT message) > This will lead to a situation where the SeGW is loaded and wanting to redi= rect some clients to another SeGW but it cannot REDIRECT them as none of the= m have indicated REDIRECT support in the IKE_SA_INIT message. > If the user/operator enabled REDIRECT functionality dynamically (like afte= r SAs were established), then the SeGW is not going to redirect them because= it had not received a REDIRECT_SUPPORTED payload from the clients. > =20 > Effect/Impact: - > This leads to a congestion/overload at the gateway when the base stations c= onnecting to the SeGW are several hundred/thousands in number. In the LTE an= d LTE-A scenarios, this condition is possible where the number of base stati= ons connecting to the SeGW are very high. > =20 > Suggestion/Solution: - > A change is required in RFC 5685 is required as below: - > =E2=80=9C=E2=80=9DWhenever the redirect feature/functionality is enabled a= t run-time, the client should indicate the same to the SeGW. This can be don= e by the client sending an INFORMATIONAL message under the protection of th= e IKE SA. This message MUST have a REDIRECT_SUPPORTED notify payload to enab= le the SeGW to redirect them at run-time even though they had initially conn= ected with SeGW without REDIRECT support=E2=80=9D=E2=80=9D > =20 > Request for comments: - > Please read the problem, impact and solution listed above and let me know i= f any comments. Hope my point is valid and needs to be incorporated as the R= FC update. > =20 > =20 > Regards, > Vijay N. > =20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 >=20 > =20 > -- > Regards, > Ahmad --Apple-Mail-85229675-9519-429A-8243-EF359B70B9A9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hell= o Vijay,

No one is trying to deviate from th= e original topic. Let me try to address what you just mentioned one more tim= e.

You just mentioned that some vendors do no= t support Reauth. But let me remind you; no vendor is supporting what you ar= e proposing now. How that becomes an argument.

On the other hand, I provided you with an example that your proposal wil= l NOT solve; while the SeGW even support REDIRECTION as per RFC5685 already;= you some how chose to ignore it. Here is the text for the reminder:
"
For e= xample: what about if the SeGW support REDIRECTION as per RFC5685 but NOT by= the newly introduced functionality (assuming that has been adopted). Althou= gh, the SeGW support REDIRECTION, but it would NOT be able to recognize and s= upport this functionality. This means that it wont work but renegotiation of= the IKE SA will still work.
"

Regards,
A= hmad

On May 5,= 2014, at 10:45 PM, vijay kn <vija= y.kn@huawei.com> wrote:

=

Praveen/Ahmad,

Some vendors don=E2=80=99t s= upport Reauth. In this case what to do?

I think we are slightly dev= iating from our original topic.

Why to do reauth which is a= n expensive operation when you can just intimate the SeGW that u support red= irect via an INFO msg.

 

 

Thanks.

 

From: Ahmad Muhan= na [mailto:asmuhanna@gmail.com]
Sent: Monday, May 05, 2014 10:48 PM
To: Praveen Sathyanarayan
Cc: vijay kn; ipsec@ietf.org; <= a href=3D"mailto:vijay@wichorus.com">vijay@wichorus.com; kilian.weniger@googlemail.com; vjkumar2003@gmail.com
Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5= 685)

 

Thanks Praveen for pointing that out.

 

That what I initially had in mind but got distracted b= y the notion that it may cause service disruption without double checking RFC= 5996.

I believe Re-authentication is the solution for this i= ssue without causing any service disruption. Although, service disruption is= imminent in case of upgrade anyway.

 

Regards,

Ahmad

 

On Mon, May 5, 2014 at 12:05 PM, Praveen Sathyanaraya= n <praveenys@j= uniper.net> wrote:

Why not trigger Re-authentication from base st= ation, when upgraded/REDIRECT enabled in config?

 

RFC 5996:

 

   Reauthenticat=
ion is done by creating a new IKE SA from scratch (using

   IKE_SA_INIT/I=
KE_AUTH exchanges, without any REKEY_SA Notify


   payloads), cr=
eating new Child SAs within the new IKE SA (without


   REKEY_SA Noti=
fy payloads), and finally deleting the old IKE SA (which


   deletes the o=
ld Child SAs as well).

 

Thanks,

Praveen

 

From: vijay kn <vijay.kn@huawei.com>
Date: Sunday, May 4, 2014 at 10:30 PM
To: Ahmad Muhanna <asmuhanna@gmail.com>
Cc: "ipsec@ietf.o= rg" <ipsec@ietf.o= rg>, "vijay@w= ichorus.com" <vijay@wichorus.com>, "kilian.= weniger@googlemail.com" <kilian.weniger@googlemail.com>, "vjkumar2003@gmail.com" <vjkumar2003@= gmail.com>
Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5= 685)

 

Hi Ahmad,

If you meant re-negotiating is IKEv2 r= ekey then it will not work because IKEv2 rekey will not send any IKE_SA_INIT= packet. As of now, the RFC says that REDIRECT_SUPPORTED payload can be sent only in IKE_SA_INIT msg.

OR<= o:p>

If you meant re-negotiating is complet= ely delete the current SA and re-negotiate the SA from scratch, this would l= ead to service loss/pkt loss.<= /span>

 

Recommendation: -

Since the base stations normally estab= lish Tunnel with other vendor base stations and/or other vendor Gateways whi= ch may or may not support  REDIRECT, it is better to add this solution (client to send a new INFO msg with the R= EDIRECT_SUPPORTED notify payload) to enable a SMOOTH inter-op with other ven= dor implementations.

 

Because of these reasons, I feel the R= FC needs correction.

 

 

From: Ah= mad Muhanna [mailto:as= muhanna@gmail.com]
Sent: Sunday, May 04, 2014 9:41 PM
To: vijay kn
Cc: vijay@wic= horus.com; kilian.we= niger@googlemail.com; ipsec@ietf.org; vjkumar2003@gmail.com
Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5= 685)

 

Hi, Vijay, 

 

I am NOT one if the authors of this RFC b= ut I recall the discussion and the use case. If I understand the scenario co= rrectly, the client in this case (eNB) negotiated an IKE SA without indicating the ability to support REDIRECT. If= that is the case, the client should renegotiate IKE SA after being upgraded= to support this functionality. My understanding renegotiating IKE SA is sup= ported.

 

IMO, I do not think that anything in thi= s RFC needs to be changed.


Regards,

Ahmad Muhanna 


On May 2, 2014, at 9:14 AM, vijay kn <vijay.kn@huawei.com> wrote:

Hi,

There is an issue in IKEv2 REDIRECT RFC 5685. In one scenario, the IKEv2 REDIRECT will not work indef= initely.

 

Scenario: -

Let=E2=80=99s assume there are about 100= 0 clients connected to a IKEv2 REDIRECT enabled SeGW. None of the clients were IKEv2 redirect enabled at the time of establishi= ng SA with the SeGW (meaning they have not sent the REDIRECT_SUPPORTED n= otification in the

IKE_SA_INIT message)

This will lead to a situation where the S= eGW is loaded and wanting to redirect some clients to another SeGW but it ca= nnot REDIRECT them as none of them have indicated REDIRECT support in the IKE_SA_INIT message.

If the user/operator enabled REDIRECT fu= nctionality dynamically (like after SAs were established), then the SeGW is n= ot going to redirect them because it had not received a REDIRECT_SUPPORTED payload from the clients.

 

Effect/Impact: -

This leads to a congestion/overload at t= he gateway when the base stations connecting to the SeGW are several hundred= /thousands in number. In the LTE and LTE-A scenarios, this condition is possible where the number of base statio= ns connecting to the SeGW are very high.

 

Suggestion/Solution: -

A change is required in RFC 5685 is requ= ired as below: -

=E2=80=9C=E2=80=9DWhenever the redirec= t feature/functionality is enabled at run-time, the client should indicate t= he same to the SeGW. This can be done by the client sending an INFORMATIONAL message  under the protection of the IKE SA. T= his message MUST have a REDIRECT_SUPPORTED notify payload to enable the SeGW= to redirect them at run-time even though they had initially connected with S= eGW without REDIRECT support=E2=80=9D=E2=80=9D

 

Request for comments: -

Please read the problem, impact and solu= tion listed above and let me know if any comments. Hope my point is valid an= d needs to be incorporated as the RFC update.

 

 

Regards,

Vijay N.

 

________________________________________= _______
IPsec mailing list
IPsec@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ipsec



 

--

Regards,

Ahmad

= --Apple-Mail-85229675-9519-429A-8243-EF359B70B9A9-- From nobody Tue May 6 05:51:09 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A076C1A02F5 for ; Tue, 6 May 2014 05:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muiuJIjAvaud for ; Tue, 6 May 2014 05:51:04 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 611EB1A02F8 for ; Tue, 6 May 2014 05:51:03 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.7) with ESMTP id s46Co3c5023256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 May 2014 15:50:03 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.7/Submit) id s46Co0KA019412; Tue, 6 May 2014 15:50:00 +0300 (EEST) 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: <21352.55928.636095.606830@fireball.kivinen.iki.fi> Date: Tue, 6 May 2014 15:50:00 +0300 From: Tero Kivinen To: Praveen Sathyanarayan In-Reply-To: References: <335B84BDA2818C428E63D9B0ADE6863545AF7228@szxeml561-mbx.china.huawei.com> <335B84BDA2818C428E63D9B0ADE6863545AF7A1A@szxeml561-mbx.china.huawei.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 26 min X-Total-Time: 27 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/pjFTmO19M6Z0MO-eNdtNsLDdzPo Cc: "ipsec@ietf.org" , Paul Wouters , Yoav Nir , Syed Ajim Hussain Subject: Re: [IPsec] Simultaneous Child SA Creation tigger from both the side. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 12:51:07 -0000 Praveen Sathyanarayan writes: > I agree, it is a corner case. Example, out of 5000 tunnels, may be we will > see 10 to 15 tunnels end up in this scenario. So memory/resource is not a > concern. There are two cases: Your implementation is very limited, and support very few Child SAs and cannot cope when there are two SAs. In that case your implementation will reply with NO_ADDITIONAL_SAS to CREATE_CHILD_SA requests coming in, when they do not have space in the Child SA table. If both ends are limited implementations and both of them reply with NO_ADDITIONAL_SAS, then following the section 4 of RFC5996 they need to delete the IKE SA and start over. ---------------------------------------------------------------------- 1.3. The CREATE_CHILD_SA Exchange ... The responder sends a NO_ADDITIONAL_SAS notification to indicate that a CREATE_CHILD_SA request is unacceptable because the responder is unwilling to accept any more Child SAs on this IKE SA. This notification can also be used to reject IKE SA rekey. Some minimal implementations may only accept a single Child SA setup in the context of an initial IKE exchange and reject any subsequent attempts to add more. ... 4. Conformance Requirements ... A minimal implementation MAY support the CREATE_CHILD_SA exchange only in so far as to recognize requests and reject them with a Notify payload of type NO_ADDITIONAL_SAS. A minimal implementation need not be able to initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA expires (based on locally configured values of either lifetime or octets passed), and implementation MAY either try to renew it with a CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and create a new one. If the responder rejects the CREATE_CHILD_SA request with a NO_ADDITIONAL_SAS notification, the implementation MUST be capable of instead deleting the old SA and creating a new one. ---------------------------------------------------------------------- If your implemenations do support multiple SAs, then you MUST accept to create two SAs, as there is no way from the responder to know why the other end is creating the SA. It might be that the other end is creating it because of this policy reload, but it might also be caused because the other end got traffic on different QoS level, and needs to create separate SA for that QoS level. Section 4.1 of RFC4301 says: ---------------------------------------------------------------------- 4.1. Definition and Scope ... 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. ... ---------------------------------------------------------------------- and Section 2.8 in RFC5996 ---------------------------------------------------------------------- 2.8. Rekeying ... Note that IKEv2 deliberately allows parallel SAs with the same Traffic Selectors between common endpoints. One of the purposes of this is to support traffic quality of service (QoS) differences among the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and Section 4.1 of [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints and the Traffic Selectors may not uniquely identify an SA between those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on the basis of duplicate Traffic Selectors SHOULD NOT be used. ---------------------------------------------------------------------- So the end result with non-minimal implementations is that there will be two Child SAs with same traffic selectors. > But question is, how do we handle once we are in that state. For > example, which phase1/phase2 SA we should continue to hold (Rekey) and > which one we need drop it, etc. > > This is where the confusion comes. Each vendor may end up choosing > different way to handle it and it may cause confusion with other vendor. > If there is a clear description on how to handle (which one to choose and > which one to drop), will help. Both of the SAs are valid and both ends needs to process packets coming from either of SA without prejudice. Each implementation will most likely pick one SA when sending traffic and it will send traffic out from that SA. Neither end should not drop SAs as it does not know why the other end created them. When it comes time to rekey, then it depends on the implementation what will happen. If both ends happened to select same SA pair for their traffic, then when it comes to time to rekey the second SA, it is dropped as there has not been traffic on it at all (there is no point of rekeying SA which do not have traffic). If they picked different SAs for their traffic and one of them is going to rekey his outbound SA, then he will rekey that and the old SA is deleted. Now the other peer might notice that when his outbound SA is about to expire, he notices that there is already good Child SA with same traffic selectors which is going to be valid, so he might simply just skip the rekeying and instead move the traffic to the other SA. Then as he didn't do rekey, then when the SA actually expires, then he will delete it. If they happened to do rekey exactly same time (both of them happen to have exactly same lifetimes), then it might be possible that both ends rekey their own outgoing SA and the situation continues. There is no possibility for getting more SAs as this is rekey, not creating new SA, so simultaneous rekeys are already covered by the protocol. Also both ends only use one SA for sending, so at most there can be two SA pairs between the peers that has traffic, and all others should not be rekeyed, as there has not been any traffic. All of that is just implementation details, not protocol issues. As there is no concept of "one Child SA per one Traffic Flow (SPD)" in the IPsec architecture, if you implement such concept you need to define how it should work. On the other hand IKEv2 do have mandatory feature that you support multiple Child SAs with same Traffic Selectors... On the other hand Traffic Flow and Traffic Selectors are not the same thing. Traffic flow could include other things which cannot be expressed in Traffic Selectors, like QoS parameters etc. -- kivinen@iki.fi From nobody Tue May 6 06:13:49 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747101A0429 for ; Tue, 6 May 2014 06:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QxzKjLaZ7RM for ; Tue, 6 May 2014 06:13:47 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 34E871A030B for ; Tue, 6 May 2014 06:13:47 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.7) with ESMTP id s46DDX7N003849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 May 2014 16:13:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.7/Submit) id s46DDXDA023985; Tue, 6 May 2014 16:13:33 +0300 (EEST) 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=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <21352.57341.564145.859848@fireball.kivinen.iki.fi> Date: Tue, 6 May 2014 16:13:33 +0300 From: Tero Kivinen To: vijay kn In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 12 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/MTYtNajASTokFkZFndBY-CWgRCw Cc: "vijay@wichorus.com" , "kilian.weniger@googlemail.com" , "ipsec@ietf.org" , Ahmad Muhanna , Praveen Sathyanarayan , "vjkumar2003@gmail.com" Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 13:13:48 -0000 vijay kn writes: > Praveen/Ahmad,> Some vendors don=E2=80=99t support Reauth. In this ca= se what > to do=3F=20 There is no specific need for reauth on the protocol level. You create new IKE SA, you create new Child SAs, you delete old IKE SA. Everything is just standard IKEv2 and all implementations support that on the protocol level. For the SGW end everything looks like the client just reconnected. For the client end you need bit more code. I.e. when client notices that policy has changed so that REDIRECT support should be turned, then instead of sending your new INFORMATIONAL exchange, it will simply do the reauthentication. This is much easier to implement than what you suggested. Also as people have already pointed out, there is NO POINT of disabling feature on the implementations, especially if you can already now see that you might need it at some point. If it cause problems because of bugs, fix those bugs. If the client implemenation does not support REDIRECT, then upgrade it, and upgrade usually means that you need to start IKE SA again anyways... > I think we are slightly deviating from our original topic. I do not think there is problem here that requires solving. We already have REDIRECT. There are ways to use it. There is way to enable it by doing reauthentication. There is actually another way to do the same thing, i.e. using MOBIKE to dynamically move SAs from one IP-address to another, and of you support suitable methods of transfering SA information to another host you can use that to move all or some IKE and IPsec SAs from one host to another without causing any disruptions. On the other hand you need to send MOBIKE=5FSUPPORTED in IKE=5FAUTH, so you cannot enable that on the fly either... And one of the use cases in RFC4621 (MOBIKE Design document) is multihomed servers, i.e. the MOBIKE do allow both ends to move. The rendezvous is outside the scope of MOBIKE, so both ends cannot move at the same time without keeping at least some of the addresses intact. > Why to do reauth which is an expensive operation when you can just in= timate > the SeGW that u support redirect via an INFO msg. If you do not want to do expensive operations, then enable the REDIRECT support from the beginning...=20 --=20 kivinen@iki.fi From nobody Wed May 7 05:50:58 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03E11A02BA; Wed, 7 May 2014 05:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjsV-Ow-9QiI; Wed, 7 May 2014 05:50:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 689981A02A5; Wed, 7 May 2014 05:50:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140507125054.15815.369.idtracker@ietfa.amsl.com> Date: Wed, 07 May 2014 05:50:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-rk3bJklYgCU_4Pz9ZbSliw33xw Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-kivinen-ipsecme-signature-auth-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 12:50:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Signature Authentication in IKEv2 Authors : Tero Kivinen Joel Snyder Filename : draft-kivinen-ipsecme-signature-auth-06.txt Pages : 17 Date : 2014-05-07 Abstract: The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group. This document generalizes IKEv2 signature support to allow any signature method supported by the PKIX and also adds signature hash algorithm negotiation. This is a generic mechanism, and is not limited to ECDSA, but can also be used with other signature algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-signature-auth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-kivinen-ipsecme-signature-auth-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-kivinen-ipsecme-signature-auth-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 7 08:31:42 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD9B1A035A for ; Wed, 7 May 2014 08:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fT8bO4JScfqD for ; Wed, 7 May 2014 08:31:40 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 757861A0311 for ; Wed, 7 May 2014 08:31:40 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s47FVYc1063134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 7 May 2014 08:31:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <20140507125054.15815.369.idtracker@ietfa.amsl.com> Date: Wed, 7 May 2014 08:31:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6DFCD87A-CDC5-4871-A3DA-D79601782CDB@vpnc.org> References: <20140507125054.15815.369.idtracker@ietfa.amsl.com> To: IPsec ME WG List X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/mClPrUIMXLH0A8d5bETFssBgsfo Subject: [IPsec] Short re-run of WG LC: draft-kivinen-ipsecme-signature-auth-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 15:31:41 -0000 Many thanks to Joel Snyder for helping clarify lots of the wording in = this document. It feels much cleaner to me. I'm not 100% convinced that = technical changes slipped in during those extensive changes. So, I'd = really like the WG to review the latest draft. If you have any new = concerns at all, please send them to the mailing list before Wednesday = May 14. --Paul Hoffman On May 7, 2014, at 5:50 AM, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Signature Authentication in IKEv2 > Authors : Tero Kivinen > Joel Snyder > Filename : draft-kivinen-ipsecme-signature-auth-06.txt > Pages : 17 > Date : 2014-05-07 >=20 > Abstract: > The Internet Key Exchange Version 2 (IKEv2) protocol has limited > support for the Elliptic Curve Digital Signature Algorithm (ECDSA). > The current version only includes support for three Elliptic Curve > groups, and there is a fixed hash algorithm tied to each group. = This > document generalizes IKEv2 signature support to allow any signature > method supported by the PKIX and also adds signature hash algorithm > negotiation. This is a generic mechanism, and is not limited to > ECDSA, but can also be used with other signature algorithms. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-signature-auth/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-kivinen-ipsecme-signature-auth-06 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-kivinen-ipsecme-signature-auth-06= From nobody Thu May 15 10:03:05 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265251A0693; Thu, 15 May 2014 10:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YY1qvunqEu15; Thu, 15 May 2014 10:02:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEE61A0416; Thu, 15 May 2014 10:02:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140515170255.32211.5747.idtracker@ietfa.amsl.com> Date: Thu, 15 May 2014 10:02:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/EQannrCLGxSf1VW4gtCqc08IJrc Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 17:03:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Authors : David McGrew Paul Hoffman Filename : draft-ietf-ipsecme-esp-ah-reqts-08.txt Pages : 11 Date : 2014-05-15 Abstract: This Internet Draft is a standards track proposal to update the Cryptographic Algorithm Implementation Requirements for ESP and AH; it also adds usage guidance to help in the selection of these algorithms. The Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols make use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms. This document obsoletes RFC 4835. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-esp-ah-reqts-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 16 10:19:20 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331581A02AE; Fri, 16 May 2014 10:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmrVsj8vLkBP; Fri, 16 May 2014 10:19:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A541A0279; Fri, 16 May 2014 10:19:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140516171916.11389.18636.idtracker@ietfa.amsl.com> Date: Fri, 16 May 2014 10:19:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/NqnPQBAjZo-nVxDiT6MQhVh7uqA Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-09.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 17:19:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Authors : David McGrew Paul Hoffman Filename : draft-ietf-ipsecme-esp-ah-reqts-09.txt Pages : 11 Date : 2014-05-16 Abstract: This Internet Draft is a standards track proposal to update the Cryptographic Algorithm Implementation Requirements for ESP and AH; it also adds usage guidance to help in the selection of these algorithms. The Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols make use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms. This document obsoletes RFC 4835. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-esp-ah-reqts-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 16 14:56:40 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348781A023E; Fri, 16 May 2014 14:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QihPA0xtpsx; Fri, 16 May 2014 14:56:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6511A0191; Fri, 16 May 2014 14:56:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140516215634.13973.81160.idtracker@ietfa.amsl.com> Date: Fri, 16 May 2014 14:56:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/nBFkyH5EYwdkMPSKmrdFr0p1o2I Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-10.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 21:56:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Authors : David McGrew Paul Hoffman Filename : draft-ietf-ipsecme-esp-ah-reqts-10.txt Pages : 11 Date : 2014-05-16 Abstract: This Internet Draft is a standards track proposal to update the Cryptographic Algorithm Implementation Requirements for ESP and AH; it also adds usage guidance to help in the selection of these algorithms. The Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols make use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms. This document obsoletes RFC 4835. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-esp-ah-reqts-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 18 19:09:43 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6A31A0257 for ; Sun, 18 May 2014 19:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqY8A07ngQ3K for ; Sun, 18 May 2014 19:09:40 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DECE41A0256 for ; Sun, 18 May 2014 19:09:39 -0700 (PDT) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4J29bFw029319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 18 May 2014 22:09:37 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s4J29bFw029319 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1400465377; bh=IfGRziEfu/WdpnZSJDY6jvlT/RI=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=xSgycPbJb0l97MxzNNRR15L1mXexWPZzy8/difBxmjlfQw9YS9J1gNl7DqgIW+R/H TvG643ol1SaOzSAQ1ljvL6K51EGxwWLFRYdbBdJMrkDVljLy7dzFGHM3dNZEKYqCQm HxYUeoAoNJk5JBCXV19KIlP2c3eyAiY5sa4v0XRQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s4J29bFw029319 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd04.lss.emc.com (RSA Interceptor) for ; Sun, 18 May 2014 19:09:28 -0700 Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.222.70.236]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4J29R17015961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 18 May 2014 22:09:27 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub15.corp.emc.com ([128.222.70.236]) with mapi; Sun, 18 May 2014 22:09:26 -0400 From: "Black, David" To: "IPsecme WG (ipsec@ietf.org)" Date: Sun, 18 May 2014 22:09:24 -0400 Thread-Topic: Minor thinko in IKEv2 rfc5996bis draft (and RFC 5996) Thread-Index: Ac9zB1qpngRaP9PJSruOtmCiCpS0gg== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C55BC0C@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/4XKIGTjJCWfG725MzAmXyz5NQqE Cc: "Black, David" Subject: [IPsec] Minor thinko in IKEv2 rfc5996bis draft (and RFC 5996) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 02:09:42 -0000 In looking for something else, I ran across a minor thinko in the rfc5996bis draft that was inherited from RFC 5996. Section 3.14, Encrypted Payload, 4th paragraph: When an authenticated encryption algorithm is used to protect the IKE SA, the construction of the Encrypted payload is different than what is described here. See [AEAD] for more information on authenticated encryption algorithms and their use in ESP. [AEAD] is a reference to RFC 5282, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol." Hence, a change is in order at the end of the paragraph: "ESP" -> "IKEv2" In the unlikely event that the IESG finds nothing else to change in the draft :-), an RFC Editor Note ought to suffice to handle this. Should I also file an erratum against RFC 5996? Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Mon May 19 00:31:09 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC6B1A0310 for ; Mon, 19 May 2014 00:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23OpSdnFNqrE for ; Mon, 19 May 2014 00:31:03 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A8791A0311 for ; Mon, 19 May 2014 00:31:03 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id r20so3620559wiv.3 for ; Mon, 19 May 2014 00:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=qNHn02tkpkYksby5xQBisD/ULiYPnt15uXu+o330fBE=; b=rDHROhJh1QbLIqXPupdQuD8Nho57IgYtDAVztLreICAu8YLqt4mCuVKf9aq0jvLNNL s/I9EffWOkA9Dn/uzEPOoZpT1/sRyxl87JGQ67HfxvtOYRjGLTbSY19mbUlThNx+ebZR NOXyhjkDSjVZdhoz1glXx3yFmWlA5DrWrQTb+Q5yVVlaRVFl5Bzb7lgSN0a0Y9i0ZWYu V1jTKqa5pKr4wFKqX6SHlRjW/QRwLEtDslV/vTlXQzKkXpsB3a62hh/y9/mttSgc9C7Z H+0c7u01bAZiw9/kCqp/BUrWBXu9fN013ySksT/QEMyRl6SNuAYGHOYkjGDECxcxGTYq sibA== X-Received: by 10.180.89.241 with SMTP id br17mr347357wib.0.1400484662080; Mon, 19 May 2014 00:31:02 -0700 (PDT) Received: from [10.2.0.48] (93-173-250-199.bb.netvision.net.il. [93.173.250.199]) by mx.google.com with ESMTPSA id b16sm13014964wjx.45.2014.05.19.00.30.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 00:30:59 -0700 (PDT) Message-ID: <5379B332.1030005@gmail.com> Date: Mon, 19 May 2014 10:30:58 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Black, David" , "IPsecme WG (ipsec@ietf.org)" References: <8D3D17ACE214DC429325B2B98F3AE712076C55BC0C@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C55BC0C@MX15A.corp.emc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/FC7-zuaYv4kzOwx72nSXM5bEJys Subject: Re: [IPsec] Minor thinko in IKEv2 rfc5996bis draft (and RFC 5996) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 07:31:05 -0000 Hi David, Thanks for detecting this glitch. I don't think this is worth an erratum, given that we are republishing the document. Thanks, Yaron On 05/19/2014 05:09 AM, Black, David wrote: > In looking for something else, I ran across a minor thinko in the > rfc5996bis draft that was inherited from RFC 5996. > > Section 3.14, Encrypted Payload, 4th paragraph: > > When an authenticated encryption algorithm is used to protect the IKE > SA, the construction of the Encrypted payload is different than what > is described here. See [AEAD] for more information on authenticated > encryption algorithms and their use in ESP. > > [AEAD] is a reference to RFC 5282, "Using Authenticated Encryption > Algorithms with the Encrypted Payload of the Internet Key Exchange > version 2 (IKEv2) Protocol." > > Hence, a change is in order at the end of the paragraph: > > "ESP" -> "IKEv2" > > In the unlikely event that the IESG finds nothing else to change in > the draft :-), an RFC Editor Note ought to suffice to handle this. > > Should I also file an erratum against RFC 5996? > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Mon May 19 07:16:38 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8736E1A036F for ; Mon, 19 May 2014 07:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtNVzay5zsHM for ; Mon, 19 May 2014 07:16:33 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335A61A0015 for ; Mon, 19 May 2014 07:16:30 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s4JEGKqK009536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 May 2014 17:16:20 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s4JEGJpd010353; Mon, 19 May 2014 17:16:19 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21370.4659.308156.313468@fireball.kivinen.iki.fi> Date: Mon, 19 May 2014 17:16:19 +0300 From: Tero Kivinen To: "Black\, David" In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C55BC0C@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712076C55BC0C@MX15A.corp.emc.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 2 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/76wqwlvjLELp8AjR16tiaQJzPes Cc: "IPsecme WG \(ipsec@ietf.org\)" Subject: [IPsec] Minor thinko in IKEv2 rfc5996bis draft (and RFC 5996) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 14:16:37 -0000 Black, David writes: > In looking for something else, I ran across a minor thinko in the > rfc5996bis draft that was inherited from RFC 5996. > > Section 3.14, Encrypted Payload, 4th paragraph: > > When an authenticated encryption algorithm is used to protect the IKE > SA, the construction of the Encrypted payload is different than what > is described here. See [AEAD] for more information on authenticated > encryption algorithms and their use in ESP. > > [AEAD] is a reference to RFC 5282, "Using Authenticated Encryption > Algorithms with the Encrypted Payload of the Internet Key Exchange > version 2 (IKEv2) Protocol." > > Hence, a change is in order at the end of the paragraph: > > "ESP" -> "IKEv2" > > In the unlikely event that the IESG finds nothing else to change in > the draft :-), an RFC Editor Note ought to suffice to handle this. Thanks. I made the change in the current xml file, i.e. so next time I make new version this change will be there. > Should I also file an erratum against RFC 5996? I do not think we want to do that, as then I would have to publish new version immediately, as the draft-kivinen-ipsecme-ikev2-rfc5996bis says it has fixes for all errata... -- kivinen@iki.fi From nobody Mon May 19 14:12:23 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C411A0404; Mon, 19 May 2014 14:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89rq0SotYEI4; Mon, 19 May 2014 14:12:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4BF1A0413; Mon, 19 May 2014 14:12:18 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140519211218.23839.71179.idtracker@ietfa.amsl.com> Date: Mon, 19 May 2014 14:12:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/erjHObhxc4pCx3U-9N7PJsQs_dA Cc: ipsecme mailing list , ipsecme chair , RFC Editor Subject: [IPsec] Protocol Action: 'Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)' to Proposed Standard (draft-ietf-ipsecme-esp-ah-reqts-10.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 21:12:21 -0000 The IESG has approved the following document: - 'Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)' (draft-ietf-ipsecme-esp-ah-reqts-10.txt) as Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Kathleen Moriarty and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts/ Technical Summary This document replaces RFC 4835 in specifying requirement levels for various cryptographic algorithms in the ESP and AH protocols. In the 7 years since that older RFC was published, the security of some algorithms diminished, while other, more secure algorithms were published and widely implemented. This information is essential for interoperable implementation of the protocols, and so the document is intended to be a Proposed Standard. Working Group Summary There was lively WG discussion around the specific algorithms and requirement levels, but no major objections. There was wide consensus that the document should be published. Document Quality Are there existing implementations of the protocol? Yes, numerous. This draft sets new new requirements for ESP and AH, motivating vendors to implement against the new recommendations. Personnel Yaron Sheffer (IPsecME WG co-chair) is the document shepherd and Kathleen Moriarty is the responsible AD. From nobody Fri May 23 07:05:00 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F39F1A0499; Fri, 23 May 2014 07:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GOoI1ZYBLo4; Fri, 23 May 2014 07:04:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D30B91A04FA; Fri, 23 May 2014 07:04:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140523140454.11226.62128.idtracker@ietfa.amsl.com> Date: Fri, 23 May 2014 07:04:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/IxGZJPOq6QavnsUcPnW5Xjh-QDY Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 14:04:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IKEv2 Fragmentation Author : Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-fragmentation-08.txt Pages : 25 Date : 2014-05-23 Abstract: This document describes the way to avoid IP fragmentation of large IKEv2 messages. This allows IKEv2 messages to traverse network devices that do not allow IP fragments to pass through. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-fragmentation-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 23 07:16:14 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D491A052E for ; Fri, 23 May 2014 07:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fW3dVSO84Jg2 for ; Fri, 23 May 2014 07:16:11 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 933B91A049F for ; Fri, 23 May 2014 07:16:11 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id mc6so4276561lab.2 for ; Fri, 23 May 2014 07:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:mime-version:content-type :content-transfer-encoding; bh=EsISk6m2N23nsL+AC6QH/uoVnmSO9iCX03/kiMUOwew=; b=aAeiRDvk2dFDRM1hhVd5ipExS+4sTY6t8qhaZv3G15MNIt7qeuYWfcPbxkrVgg/sJM pk0BDRcBkPeGIJcbFIpz74ith+RH9MyEU7/dL3gmSbLdZcGby3tNldkN4jP9uIsdP/Sj BOs3oQltLQ7Z3gEHlM/ehQ66QiZtlVw+DI60XCTcmeR/SDKuVqODZH1P+Nh4jZTIgQP5 aTd87iqk0t+vjd47IIC0+mpHp5HYRxJGglQGUOrxWNoUUsiJUOCLdjjR9Oa83RChRdny D6NFQTiKL9HCNINZ+BGEzum7W+3QBIzoEJgfj2zqKUnj/ZDN2ivxR3b2TVcmaeKiL4Zm 2s2Q== X-Received: by 10.112.171.101 with SMTP id at5mr1314146lbc.83.1400854568550; Fri, 23 May 2014 07:16:08 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id q2sm2670654laj.9.2014.05.23.07.16.07 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 23 May 2014 07:16:07 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: Date: Fri, 23 May 2014 18:15:53 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/d6RHMxey145HJIVbv0LlEfK4jfk Subject: [IPsec] Fw: I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 14:16:13 -0000 Hi all, I've posted a new version of the document. It addresses comments, that were articulated during IESG evaluation. In particular: more clarifications are added, RFC2119 keywords are used more carefully, guidelines are made more clear, more words are added to Introduction and PMTU discovery sections, the overall language is improved (at least I hope). Regards, Valery Smyslov. ----- Original Message ----- From: To: Cc: Sent: Friday, May 23, 2014 6:04 PM Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-08.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Security Maintenance and Extensions > Working Group of the IETF. > > Title : IKEv2 Fragmentation > Author : Valery Smyslov > Filename : draft-ietf-ipsecme-ikev2-fragmentation-08.txt > Pages : 25 > Date : 2014-05-23 > > Abstract: > This document describes the way to avoid IP fragmentation of large > IKEv2 messages. This allows IKEv2 messages to traverse network > devices that do not allow IP fragments to pass through. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-fragmentation-08 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri May 23 10:22:51 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87111A021A for ; Fri, 23 May 2014 10:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZj9qsLG3xbe for ; Fri, 23 May 2014 10:22:47 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C3E1A0218 for ; Fri, 23 May 2014 10:22:45 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id m15so5145065wgh.20 for ; Fri, 23 May 2014 10:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=vjIKjDwYq39mTDanXKZIT5g3BOY7NvPO7lXWvVMFFds=; b=odedqrFHd95+7AuQq71jAe/CZZPqgK0b4idXDmQNHf3Yh8b5D/R3HQUeIR6mVl1BwH JLlnBktyljd5UxOJMWsPpSMyKpwShPu8aTAmBd8/25TL3MgWFcTFVB5FHZRANS5PuJ3Z X5CluBIeoSlBrOQSIWV8EfszEUxRdu4Tj5Y38MWh0SWpIfmxcc+h0dLPzjtdt8Lk1an8 yNhcyOM2IlNnGq6oU9mZT/YBnTKE1696Ben6yTIGtloNoxBPGi8wrWJwV0XvCPg4W0PA 2EkMKhCnXNJoRNm0NXjONdfeKbhH4XD4+EC89M/Wk96raUBWN9pVyelpqOEs4HkrFEB7 fhMQ== X-Received: by 10.180.93.226 with SMTP id cx2mr4670061wib.16.1400865762805; Fri, 23 May 2014 10:22:42 -0700 (PDT) Received: from [10.0.0.5] (bzq-109-64-4-215.red.bezeqint.net. [109.64.4.215]) by mx.google.com with ESMTPSA id lz11sm3944325wic.0.2014.05.23.10.22.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 May 2014 10:22:42 -0700 (PDT) Message-ID: <537F83E1.9000600@gmail.com> Date: Fri, 23 May 2014 20:22:41 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: IPsecME WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/QXKFHHL9otfByJBnHYDb6YgjShI Subject: [IPsec] Stopping work on Auto-Discovery VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 17:22:48 -0000 Dear WG members, After being unable to reach consensus on a protocol that solves the AD VPN problem, we set up a smaller group to discuss the solutions on the table and try to reach agreement between the competing proposals. Unfortunately, this approach was similarly unsuccessful even after multiple phone calls with the respective authors. As a result, the chairs have decided to officially withdraw this work item from the group's agenda. We will work with the ADs to remove it from our charter. We would like to thank the authors of RFC 7018 (Auto-Discovery VPN Problem Statement and Requirements), and encourage the authors of the protocol proposals to publish them for the benefit of the community. Regards, Paul and Yaron From nobody Mon May 26 00:34:45 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90ACA1A002A for ; Mon, 26 May 2014 00:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahZfnVs7S3l4 for ; Mon, 26 May 2014 00:34:42 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00C401A0024 for ; Mon, 26 May 2014 00:34:41 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id k14so3252970wgh.31 for ; Mon, 26 May 2014 00:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=Ns4FgOX4KbjIVXLQKbOQOiKaIAgi2Y6rk6QQPEPrdmQ=; b=ReqLEPafNeIZ2bBOpMxHmI+tyYMFRydfL6M6a3QnALAVSdb1gwz/ODcAHEkSwqqDOI dEBk5gRVeqan94209GJuDqTKV53WjX57mwxNS4q9sxG/M9Jfx2jd7XBNYb0L+ALcZbWX ZVlsSQ6frKI/g2S3wyhHszi837IGFHXTiJycgl9r1PHKV4XhmAoy1OMnPDnpuj5C1fjB K4U5oE+0kbvfHgjRkktyc1msQJgfUN+LEx148cKzg+rPR2j0SMuRkqPEZofSLwDTkgq2 UQ1r7NP+feuNBBnT6fth3SGCqpN8HPyyc0uZuzlm1fLl4Fwg/UkpLLYwk83zkqimRNtD 6qKQ== X-Received: by 10.180.108.106 with SMTP id hj10mr19930511wib.53.1401089677520; Mon, 26 May 2014 00:34:37 -0700 (PDT) Received: from [172.24.249.169] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id mw4sm24624387wib.12.2014.05.26.00.34.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 May 2014 00:34:37 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: <537F83E1.9000600@gmail.com> Date: Mon, 26 May 2014 10:34:32 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0D0BE798-BF3A-491D-B29A-3FF029C7DDB0@gmail.com> References: <537F83E1.9000600@gmail.com> To: IPsecME WG X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/RRiIP6e2hSbOjHfVkSc5k0xYj1o Subject: Re: [IPsec] Stopping work on Auto-Discovery VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 07:34:43 -0000 On May 23, 2014, at 8:22 PM, Yaron Sheffer = wrote: > Dear WG members, >=20 > After being unable to reach consensus on a protocol that solves the AD = VPN problem, we set up a smaller group to discuss the solutions on the = table and try to reach agreement between the competing proposals. = Unfortunately, this approach was similarly unsuccessful even after = multiple phone calls with the respective authors. >=20 > As a result, the chairs have decided to officially withdraw this work = item from the group's agenda. We will work with the ADs to remove it = from our charter. >=20 > We would like to thank the authors of RFC 7018 (Auto-Discovery VPN = Problem Statement and Requirements), and encourage the authors of the = protocol proposals to publish them for the benefit of the community. >=20 > Regards, >=20 > Paul and Yaron FWIW, I think this is the wrong decision. Both the working group and = apparently the market have shown a desire for a dynamic, large-scale = VPN, and we have enough people willing to do work on a solution. Yes, there are some designs floating around and some implementations at = various levels of maturity, and there was a lot of controversy. Not = coming up with a single, standard design will lead to multiple = non-interoperable implementations, a fragmented market, and vendor = lock-in, which runs contrary to the mission of the IETF to make the = Internet better. Implementers will be forced to either =93choose sides=94 = or worse, implement more than one design, and lacking a standard = document, much of the actual protocol will be either vendor-specific or = reverse-engineered.=20 This is exactly the kind of bad outcome that standards bodies are = supposed to prevent, and I don=92t believe that admitting defeat is the = right decision here. Yoav From nobody Mon May 26 00:37:39 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28B31A002E for ; Mon, 26 May 2014 00:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKYRIa1Oaahw for ; Mon, 26 May 2014 00:37:33 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A23011A0024 for ; Mon, 26 May 2014 00:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5606; q=dns/txt; s=iport; t=1401089851; x=1402299451; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0qUKevGuZVljVWiL0P3vLS1nKOcyVP4rwVmAPBjoqkA=; b=Ux9tD71U5kfMWKOCQyuldSTBy5EHFtnQ4ZD/RQiwduNOKEqxUrvcSsnJ Oxf/oHuVBL6pwM26foV8QoDC3a4rvMi5xWMHj0qWa6XVEycq21vI1P+wQ Xg2PpZkC8sbIeGGIqqzsNs5pbOXO+iRCrGddZeivUQVKbgdbpvn6WtUBk 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEJADHuglOtJA2D/2dsb2JhbABZgwdSUQe6VIc6AYEOFnSCJQEBAQQBAQE3KwkJDgQCAQgRBAEBCxQJBycLFAkIAgQBCQkIAYg5CAXXCxeOAQEBHjMFBoMlgRUEmzCRaoM4bIEKOQ X-IronPort-AV: E=Sophos;i="4.98,911,1392163200"; d="scan'208";a="327908064" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP; 26 May 2014 07:37:30 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s4Q7bUWx026126 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 May 2014 07:37:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Mon, 26 May 2014 02:37:29 -0500 From: "Amjad Inamdar (amjads)" To: "Black, David" , "Rajeshwar Singh Jenwar (rsj)" , "IPsecme WG (ipsec@ietf.org)" Thread-Topic: New Version Notification for draft-amjads-ipsecme-ikev2-data-channel-01.txt Thread-Index: AQHPPeiO1qUsOYKQVUCWirQNN+fFNJren44AgDhRGQCAExQE0IAAfquggChreXA= Date: Mon, 26 May 2014 07:37:29 +0000 Message-ID: <62922D1DB814EF458679925ECD8AA68D242D244C@xmb-rcd-x10.cisco.com> References: <20140312114328.20101.44457.idtracker@ietfa.amsl.com> <8D3D17ACE214DC429325B2B98F3AE712076C2EC424@MX15A.corp.emc.com> <62922D1DB814EF458679925ECD8AA68D242A33ED@xmb-rcd-x10.cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076C43817A@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C43817A@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/zd60cQjN_q_H11WiMdMv9RcQeUo Subject: Re: [IPsec] New Version Notification for draft-amjads-ipsecme-ikev2-data-channel-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 07:37:35 -0000 Hi David, I glanced through RFC 5405 and I think the unacknowledged UDP based data tr= ansfer provided by IKEv2 data channel is similar to DTLS and IPSec-over-UDP= (used with NAT-T). Please let me know if I am missing anything here. Thanks, -Amjad -----Original Message----- From: Black, David [mailto:david.black@emc.com]=20 Sent: Wednesday, April 30, 2014 7:53 PM To: Amjad Inamdar (amjads); Rajeshwar Singh Jenwar (rsj); IPsecme WG (ipsec= @ietf.org) Subject: RE: New Version Notification for draft-amjads-ipsecme-ikev2-data-c= hannel-01.txt Amjad, I'm sorry, but that would be incorrect; please read RFC 5405 and apply its = design guidance. Thanks, --David (Transport Directorate member and tsvwg WG co-chair) > -----Original Message----- > From: Amjad Inamdar (amjads) [mailto:amjads@cisco.com] > Sent: Wednesday, April 30, 2014 2:52 AM > To: Black, David; Rajeshwar Singh Jenwar (rsj); IPsecme WG=20 > (ipsec@ietf.org) > Subject: RE: New Version Notification for=20 > draft-amjads-ipsecme-ikev2-data- channel-01.txt >=20 > Hi David, >=20 > In the new version (version 1) of the draft, unlike IKEv2 control=20 > packets the data packets are not acknowledged and hence the comments=20 > on congestion and windowing no longer apply. >=20 > Thanks, > -Amjad >=20 > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Black, David > Sent: Friday, April 18, 2014 3:58 AM > To: Rajeshwar Singh Jenwar (rsj); IPsecme WG (ipsec@ietf.org) > Subject: Re: [IPsec] New Version Notification for=20 > draft-amjads-ipsecme-ikev2- data-channel-01.txt >=20 > Well, Joe Touch's comments on congestion still apply: >=20 > http://www.ietf.org/mail-archive/web/ipsec/current/msg08654.html >=20 > I suggest consulting RFC 5405 on this topic, and applying its guidance. >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Rajeshwar=20 > > Singh Jenwar (rsj) > > Sent: Wednesday, March 12, 2014 10:27 PM > > To: IPsecme WG (ipsec@ietf.org) > > Subject: [IPsec] FW: New Version Notification for > > draft-amjads-ipsecme-ikev2- data-channel-01.txt > > > > Hi, > > > > We (Amjad and I) have published new version of "Data over IKEv2 for=20 > > application security" draft based on inputs/comments received. > > Please review and provide comments/inputs/questions. > > > > Kind Regards, > > Raj > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Wednesday, March 12, 2014 5:13 PM > > To: Amjad Inamdar (amjads); Rajeshwar Singh Jenwar (rsj); Rajeshwar=20 > > Singh Jenwar (rsj); Amjad Inamdar (amjads) > > Subject: New Version Notification for > > draft-amjads-ipsecme-ikev2-data-channel- > > 01.txt > > > > > > A new version of I-D, draft-amjads-ipsecme-ikev2-data-channel-01.txt > > has been successfully submitted by Amjad S. Inamdar and posted to=20 > > the IETF repository. > > > > Name: draft-amjads-ipsecme-ikev2-data-channel > > Revision: 01 > > Title: IKEv2 based lightweight secure data communication draft- > > amjads-ipsecme-ikev2-data-channel-01 (D-IKE) > > Document date: 2014-03-12 > > Group: Individual Submission > > Pages: 15 > > URL: http://www.ietf.org/internet-drafts/draft-amjads-ipsecm= e- > > ikev2-data-channel-01.txt > > Status: https://datatracker.ietf.org/doc/draft-amjads-ipsecme-i= kev2- > > data-channel/ > > Htmlized: http://tools.ietf.org/html/draft-amjads-ipsecme-ikev2-d= ata- > > channel-01 > > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-amjads-ipsecme= -ikev2- > > data-channel-01 > > > > Abstract: > > The Internet Key Exchange (IKEv2) protocol provides authentication, > > confidentiality, integrity, data-origin authentication and anti- > > replay. Currently, IKEv2 is mainly used as a control channel to > > negotiate IPsec SA(s). IPsec is not well suited to provide transpor= t > > layer security for applications as it resides at the network layer > > and most of the IPsec implementations require integration into > > operating systems making it difficult to deploy. IPsec uses > > different sessions for control and data traffic which is not NAT and > > load balancer friendly. TLS/DTLS, the other popular security > > mechanism to provide the above security services does not mandate > > mutual peer authentication and Diffie Hellman exchange. > > > > This document describes an IKEv2 based lightweight secure data > > communication protocol and a way to provide transport layer security > > for UDP client/server applications. The protocol provides integrity > > protected encryption and integrity-only protection based on > > application needs. As most of the IoT applications are UDP based, > > IKEv2 can be used for key management as well secure data > > communication in IoT due to its simplicity, scalability, > > lightweightedness and ease of deployment. > > > > > > > > > > Please note that it may take a couple of minutes from the time of=20 > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon May 26 07:36:25 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB08C1A0160 for ; Mon, 26 May 2014 07:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2oXyRUq9p9q for ; Mon, 26 May 2014 07:36:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5981A0167 for ; Mon, 26 May 2014 07:36:21 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CAD372002C; Mon, 26 May 2014 10:38:57 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id BDE2263B0E; Mon, 26 May 2014 10:36:14 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id AB12A63B09; Mon, 26 May 2014 10:36:14 -0400 (EDT) From: Michael Richardson To: Yoav Nir In-Reply-To: <0D0BE798-BF3A-491D-B29A-3FF029C7DDB0@gmail.com> References: <537F83E1.9000600@gmail.com> <0D0BE798-BF3A-491D-B29A-3FF029C7DDB0@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-a1IOmtsbICcM4q2AM8EfqBYHR4 Cc: IPsecME WG Subject: Re: [IPsec] Stopping work on Auto-Discovery VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 14:36:23 -0000 Yoav Nir wrote: > FWIW, I think this is the wrong decision. Both the working group and > apparently the market have shown a desire for a dynamic, large-scale > VPN, and we have enough people willing to do work on a solution. > Yes, there are some designs floating around and some implementations = at > various levels of maturity, and there was a lot of controversy. Not > coming up with a single, standard design will lead to multiple > non-interoperable implementations, a fragmented market, and vendor > lock-in, which runs contrary to the mission of the IETF to make the > Internet better. Implementers will be forced to either =E2=80=9Cchoos= e sides=E2=80=9D > or worse, implement more than one design, and lacking a standard > document, much of the actual protocol will be either vendor-specific = or > reverse-engineered. I think that the chairs were underwelmed by the number of comments and the amount of review that the proposals got. Yes, I know that you, and I and Tero had opinions, but that was pretty much it. My impression is that the people who *want* a solution to this are not satisfied unless certain *critical* parties agree to come to the table. As such, going forward with any standard which does not include those parties takes a lot of effort, and, yet results in the same bad situation that you mention. I would rather one design. -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Mon May 26 11:41:56 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735771A0201 for ; Mon, 26 May 2014 11:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEJK0cYeCxnk for ; Mon, 26 May 2014 11:41:50 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D29C1A0039 for ; Mon, 26 May 2014 11:41:50 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id t60so8580873wes.27 for ; Mon, 26 May 2014 11:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qK93jIHSdRF5J6DvG2Da/UsC7ZW9KozUcusfEHM1MGM=; b=F9uoTdz3+l8ZjpE7vzQBUW5HGuNIFpLSQYgqfLpKmBcQQEi9IGV3XNJsVow09X2GKz ZGqYz5nJRMyqkIus8rJHG5o94IZ2xHIvsmdG/PjGjBujWbDQJMgYgQc3v0gd71BOGoc1 YcmGnEmXZ2aM4NTun49NGbZd0Be0nGAJGe5Fye8RyIu4HvvnpG//Cs+OEP0Mc6csLTyG oOH3MAsvlfrzIDnjdrqf2JHMcW2Eu1bPsUzJ6AAv4MZAw305bksGWXQTQe6+v9zhhr2D QzlypFlGz++7s2T7frUhcqMLxkwKim9KDoEKQYwpZ6Yf7YHYFWms2bUfwwLQl/3ijTze 0zfg== X-Received: by 10.194.175.106 with SMTP id bz10mr6961095wjc.96.1401129706481; Mon, 26 May 2014 11:41:46 -0700 (PDT) Received: from [192.168.1.101] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id vp5sm28778951wjc.31.2014.05.26.11.41.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 May 2014 11:41:45 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: <12623.1401114974@sandelman.ca> Date: Mon, 26 May 2014 21:41:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <537F83E1.9000600@gmail.com> <0D0BE798-BF3A-491D-B29A-3FF029C7DDB0@gmail.com> <12623.1401114974@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/DMIkY_m8cz9XTYOckEqlV4xRAPs Cc: IPsecME WG Subject: Re: [IPsec] Stopping work on Auto-Discovery VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 18:41:52 -0000 On May 26, 2014, at 5:36 PM, Michael Richardson = wrote: >=20 > Yoav Nir wrote: >> FWIW, I think this is the wrong decision. Both the working group and >> apparently the market have shown a desire for a dynamic, large-scale >> VPN, and we have enough people willing to do work on a solution. >=20 >> Yes, there are some designs floating around and some implementations = at >> various levels of maturity, and there was a lot of controversy. Not >> coming up with a single, standard design will lead to multiple >> non-interoperable implementations, a fragmented market, and vendor >> lock-in, which runs contrary to the mission of the IETF to make the >> Internet better. Implementers will be forced to either =93choose = sides=94 >> or worse, implement more than one design, and lacking a standard >> document, much of the actual protocol will be either vendor-specific = or >> reverse-engineered. >=20 > I think that the chairs were underwelmed by the number of comments and = the > amount of review that the proposals got. Yes, I know that you, and I = and > Tero had opinions, but that was pretty much it. There were a few others: Steve Kent, Brian Weis, Andreas Steffen, and = Paul Wouters, plus some people who hadn=92t participated in the WG = before. Those who are draft authors (about 10 of us all told) were told to stay = out of the discussion. > My impression is that the people who *want* a solution to this are not > satisfied unless certain *critical* parties agree to come to the = table. As > such, going forward with any standard which does not include those > parties takes a lot of effort, and, yet results in the same bad = situation > that you mention. >=20 > I would rather one design. One is better than three. One is also much better than zero. Yoav From nobody Mon May 26 12:01:07 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41B11A0272 for ; Mon, 26 May 2014 12:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcTj8AswDjtW for ; Mon, 26 May 2014 12:01:01 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDAD91A0286 for ; Mon, 26 May 2014 12:01:00 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 17C0D807D4; Mon, 26 May 2014 15:00:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1401130856; bh=pdNTO5v45V0J6xlerWO3hGyrEqZerNNIDFAIMqbd8VA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=nHBqOTZmv34oXYck5R+eV+P3vCts0XZ7YME9+mit0M85j5Ub26uw11r7ibnEaagn8 J7zhVb86TX0yVBbgf0rj9/29kCvjUyNNqCFlzMaSGivE0jvxrVCKIAHyquIUOQMOZJ 19NR2Arcgc7PJ6gt54AryJTQbL2UkBoPKyUHHHUA= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s4QJ0tH2023656; Mon, 26 May 2014 15:00:55 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 26 May 2014 15:00:55 -0400 (EDT) From: Paul Wouters To: Yoav Nir In-Reply-To: Message-ID: References: <537F83E1.9000600@gmail.com> <0D0BE798-BF3A-491D-B29A-3FF029C7DDB0@gmail.com> <12623.1401114974@sandelman.ca> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/GZOXNr4gFIdRUITM7Q1fGkbjnn4 Cc: IPsecME WG Subject: Re: [IPsec] Stopping work on Auto-Discovery VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 19:01:05 -0000 On Mon, 26 May 2014, Yoav Nir wrote: >> I think that the chairs were underwelmed by the number of comments and the >> amount of review that the proposals got. Yes, I know that you, and I and >> Tero had opinions, but that was pretty much it. > > There were a few others: Steve Kent, Brian Weis, Andreas Steffen, and Paul Wouters, plus some people who hadn’t participated in the WG before. > > Those who are draft authors (about 10 of us all told) were told to stay out of the discussion. > One is better than three. One is also much better than zero. Then, and now even more, I've become more afraid of bells and whistles and kitchen sinks in IKEv2. There is already a lot of criticism that IKE/IPsec is too much "designed by committee". I am not sure if we are served well by one spec that has features of all three proposals. On top of that, it seemed this work was mostly driven by allowing less specified policies to "fix themselves" into more specified. And I haven't been convinced these solutions are at the right layer. We are definitely adding more features than we can obsolete :/ Perhaps our parents should tell us to get rid of some of our old barely toys before we can ask for new ones :P Paul From nobody Mon May 26 12:42:27 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D381A024D for ; Mon, 26 May 2014 12:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmaB1k1-O3Og for ; Mon, 26 May 2014 12:42:23 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C65B1A023D for ; Mon, 26 May 2014 12:42:23 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so493106wib.11 for ; Mon, 26 May 2014 12:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1RA8Q9QaEOwc7DroLZr0zHUzfyk/stcyOq6ch130bEY=; b=mXgVsy0Qqmdwh7/dER/VKnkPdjLajlwkQNCTUWyhRHWNlpfg24+VHs3yyqvNQfFj2m x9eO/czk2cq51iNZyjDVGEoMo5K9fNrmRpea4vf/hbG1fzRUChEh8Nuji7/OYr7AOMHp YWdJvfku6faEm0GpeGm+tBlS0YUY5ItnV3nj+YB8/AqLjaT48udbtdyBZprLIjWemzKP uHiB5obHzj3tdbiygjRdKVVoVJQvaF1mQj3o90D6aXiEqDvT+afXRm+jXTuxFal1tXlB n6I9tcq1Opqi+K4wQQ8rWzGLTyHbMb/GBYHXlGki1JJ/j1HMpWH2v9YzbCJhPMurF8q0 lSKQ== X-Received: by 10.194.243.104 with SMTP id wx8mr32742456wjc.32.1401133339406; Mon, 26 May 2014 12:42:19 -0700 (PDT) Received: from [192.168.1.101] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id hr4sm29132186wjb.28.2014.05.26.12.42.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 May 2014 12:42:18 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: Date: Mon, 26 May 2014 22:42:01 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <537F83E1.9000600@gmail.com> <0D0BE798-BF3A-491D-B29A-3FF029C7DDB0@gmail.com> <12623.1401114974@sandelman.ca> To: Paul Wouters X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/xj_skSIJCwGbl8xEdk_4LNrNQU8 Cc: IPsecME WG Subject: Re: [IPsec] Stopping work on Auto-Discovery VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 19:42:25 -0000 On May 26, 2014, at 10:00 PM, Paul Wouters wrote: >=20 > We are definitely adding more features than we can obsolete :/ Perhaps > our parents should tell us to get rid of some of our old barely toys > before we can ask for new ones :P Can we trade in AH and IKEv1=92s =93new group mode=94 for a dynamic = policy? I=92ll throw in transport mode, if needed. Yoav= From nobody Tue May 27 05:21:51 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D345B1A00FE for ; Tue, 27 May 2014 05:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-Rl0qZkD8yQ for ; Tue, 27 May 2014 05:21:46 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D831A0037 for ; Tue, 27 May 2014 05:21:45 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4RCLeCx029517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 May 2014 08:21:41 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s4RCLeCx029517 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1401193301; bh=a78r/frVFa5LkJrGENQfyEdbI38=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ks70qGwl+CvCbnRBGuRX3jdgDxNpNSUbu/eJamvS6lUk8FVXzAmzwZmjyOmaEw5Z2 KGwwAOVOWF9vXB44lTFEXLKXrIluxwPxXEaIUwK0YPs1TEIMdasUox4jLRHqHp3YB+ OXTF3DLWcLmfypmxoDRRydSHQ98810ysEqrjUZkE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s4RCLeCx029517 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd03.lss.emc.com (RSA Interceptor); Tue, 27 May 2014 08:21:32 -0400 Received: from mxhub25.corp.emc.com (mxhub25.corp.emc.com [10.254.110.181]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4RCLVhb008025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 May 2014 08:21:31 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub25.corp.emc.com ([10.254.110.181]) with mapi; Tue, 27 May 2014 08:21:30 -0400 From: "Black, David" To: "Amjad Inamdar (amjads)" , "IPsecme WG (ipsec@ietf.org)" Date: Tue, 27 May 2014 08:21:29 -0400 Thread-Topic: New Version Notification for draft-amjads-ipsecme-ikev2-data-channel-01.txt Thread-Index: AQHPPeiO1qUsOYKQVUCWirQNN+fFNJren44AgDhRGQCAExQE0IAAfquggChreXCAAeB1UA== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C66300C@MX15A.corp.emc.com> References: <20140312114328.20101.44457.idtracker@ietfa.amsl.com> <8D3D17ACE214DC429325B2B98F3AE712076C2EC424@MX15A.corp.emc.com> <62922D1DB814EF458679925ECD8AA68D242A33ED@xmb-rcd-x10.cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076C43817A@MX15A.corp.emc.com> <62922D1DB814EF458679925ECD8AA68D242D244C@xmb-rcd-x10.cisco.com> In-Reply-To: <62922D1DB814EF458679925ECD8AA68D242D244C@xmb-rcd-x10.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 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/AgsglEPOKZDlLeTVW7K-IoNg5Rw Subject: Re: [IPsec] New Version Notification for draft-amjads-ipsecme-ikev2-data-channel-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 12:21:49 -0000 Hi Amjad, > I glanced through RFC 5405 and I think the unacknowledged UDP based data > transfer provided by IKEv2 data channel is similar to DTLS and IPSec-over= -UDP > (used with NAT-T). Please let me know if I am missing anything here. Sure, Joe originally wrote: > This mechanism lacks congestion control, and so needs to be used only > where its load is known to be a small fraction of capacity. In specific, > IKE's window mechanism allows for increasing the window size but not > decreasing it, as is needed to react to network congestion. >=20 > The acknowledged data transfer mode uses IKE's window mechanism, which > is presumably set to a small value, and may result in very low throughput= . > Attempts to increase this window size to overcome this limitation can > easily increase burstiness and network loss. I believe both comments continue to apply. IKEv2 is self-limiting in its use of UDP courtesy of IKEv2's exchange structure; this draft proposes to c= hange that. If the intended use case really is IoT, then something can be said about the limited amount/rate of traffic that is involved. Thanks, --David > -----Original Message----- > From: Amjad Inamdar (amjads) [mailto:amjads@cisco.com] > Sent: Monday, May 26, 2014 3:37 AM > To: Black, David; Rajeshwar Singh Jenwar (rsj); IPsecme WG (ipsec@ietf.or= g) > Subject: RE: New Version Notification for draft-amjads-ipsecme-ikev2-data= - > channel-01.txt >=20 > Hi David, >=20 > I glanced through RFC 5405 and I think the unacknowledged UDP based data > transfer provided by IKEv2 data channel is similar to DTLS and IPSec-over= -UDP > (used with NAT-T). Please let me know if I am missing anything here. >=20 > Thanks, > -Amjad >=20 > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Wednesday, April 30, 2014 7:53 PM > To: Amjad Inamdar (amjads); Rajeshwar Singh Jenwar (rsj); IPsecme WG > (ipsec@ietf.org) > Subject: RE: New Version Notification for draft-amjads-ipsecme-ikev2-data= - > channel-01.txt >=20 > Amjad, >=20 > I'm sorry, but that would be incorrect; please read RFC 5405 and apply it= s > design guidance. >=20 > Thanks, > --David (Transport Directorate member and tsvwg WG co-chair) >=20 > > -----Original Message----- > > From: Amjad Inamdar (amjads) [mailto:amjads@cisco.com] > > Sent: Wednesday, April 30, 2014 2:52 AM > > To: Black, David; Rajeshwar Singh Jenwar (rsj); IPsecme WG > > (ipsec@ietf.org) > > Subject: RE: New Version Notification for > > draft-amjads-ipsecme-ikev2-data- channel-01.txt > > > > Hi David, > > > > In the new version (version 1) of the draft, unlike IKEv2 control > > packets the data packets are not acknowledged and hence the comments > > on congestion and windowing no longer apply. > > > > Thanks, > > -Amjad > > > > -----Original Message----- > > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Black, David > > Sent: Friday, April 18, 2014 3:58 AM > > To: Rajeshwar Singh Jenwar (rsj); IPsecme WG (ipsec@ietf.org) > > Subject: Re: [IPsec] New Version Notification for > > draft-amjads-ipsecme-ikev2- data-channel-01.txt > > > > Well, Joe Touch's comments on congestion still apply: > > > > http://www.ietf.org/mail-archive/web/ipsec/current/msg08654.html > > > > I suggest consulting RFC 5405 on this topic, and applying its guidance. > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Rajeshwar > > > Singh Jenwar (rsj) > > > Sent: Wednesday, March 12, 2014 10:27 PM > > > To: IPsecme WG (ipsec@ietf.org) > > > Subject: [IPsec] FW: New Version Notification for > > > draft-amjads-ipsecme-ikev2- data-channel-01.txt > > > > > > Hi, > > > > > > We (Amjad and I) have published new version of "Data over IKEv2 for > > > application security" draft based on inputs/comments received. > > > Please review and provide comments/inputs/questions. > > > > > > Kind Regards, > > > Raj > > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > Sent: Wednesday, March 12, 2014 5:13 PM > > > To: Amjad Inamdar (amjads); Rajeshwar Singh Jenwar (rsj); Rajeshwar > > > Singh Jenwar (rsj); Amjad Inamdar (amjads) > > > Subject: New Version Notification for > > > draft-amjads-ipsecme-ikev2-data-channel- > > > 01.txt > > > > > > > > > A new version of I-D, draft-amjads-ipsecme-ikev2-data-channel-01.txt > > > has been successfully submitted by Amjad S. Inamdar and posted to > > > the IETF repository. > > > > > > Name: draft-amjads-ipsecme-ikev2-data-channel > > > Revision: 01 > > > Title: IKEv2 based lightweight secure data communication draft- > > > amjads-ipsecme-ikev2-data-channel-01 (D-IKE) > > > Document date: 2014-03-12 > > > Group: Individual Submission > > > Pages: 15 > > > URL: http://www.ietf.org/internet-drafts/draft-amjads-ipse= cme- > ikev2-data-channel-01.txt > > > Status: https://datatracker.ietf.org/doc/draft-amjads-ipsecme= - > ikev2- > > > data-channel/ > > > Htmlized: http://tools.ietf.org/html/draft-amjads-ipsecme-ikev2= - > data- > > > channel-01 > > > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-amjads-ipsec= me- > ikev2- > > > data-channel-01 > > > > > > Abstract: > > > The Internet Key Exchange (IKEv2) protocol provides authentication= , > > > confidentiality, integrity, data-origin authentication and anti- > > > replay. Currently, IKEv2 is mainly used as a control channel to > > > negotiate IPsec SA(s). IPsec is not well suited to provide transp= ort > > > layer security for applications as it resides at the network layer > > > and most of the IPsec implementations require integration into > > > operating systems making it difficult to deploy. IPsec uses > > > different sessions for control and data traffic which is not NAT a= nd > > > load balancer friendly. TLS/DTLS, the other popular security > > > mechanism to provide the above security services does not mandate > > > mutual peer authentication and Diffie Hellman exchange. > > > > > > This document describes an IKEv2 based lightweight secure data > > > communication protocol and a way to provide transport layer securi= ty > > > for UDP client/server applications. The protocol provides integri= ty > > > protected encryption and integrity-only protection based on > > > application needs. As most of the IoT applications are UDP based, > > > IKEv2 can be used for key management as well secure data > > > communication in IoT due to its simplicity, scalability, > > > lightweightedness and ease of deployment. > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > > > The IETF Secretariat > > > > > > _______________________________________________ > > > 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 From nobody Thu May 29 00:35:46 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81061A0764 for ; Thu, 29 May 2014 00:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Lj2cIcRos_v for ; Thu, 29 May 2014 00:35:42 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51AA61A0789 for ; Thu, 29 May 2014 00:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8397; q=dns/txt; s=iport; t=1401348939; x=1402558539; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=DIDdXO0A2TuaAoltsiUIYZ8hnAJfsfHWQPmZBb0jWa4=; b=Y8SVsB/ftRrLIy9pfbYM6S23tWynOemOCRCvd6ef+6U3AC7/aeVGWV/E uXPa5ews2if4J4Aer5j916p14ffVMitEE/Bz0kqLE3WeE8j34WIzxULZD OdCKwQ2v6iGm4J0ac9Gcs3wDVUN+2o97Nk1OwMC8Xnz7ZZ9xi3tmkk+LE o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwIALrihlOtJV2c/2dsb2JhbABZgwdSUQe6e4dAAYERFnSCJQEBAQMBAQEBNysJCQcHBAIBCBEEAQELFAkHJwsUCQgCBAEJCQgBiDEICAXXRheNegcBAR4zBQaDJYEVBJsykWuDOGyBAQkXIg X-IronPort-AV: E=Sophos;i="4.98,932,1392163200"; d="scan'208";a="328773123" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 29 May 2014 07:35:38 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s4T7Zbtf010102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 May 2014 07:35:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Thu, 29 May 2014 02:35:37 -0500 From: "Amjad Inamdar (amjads)" To: "Black, David" , "IPsecme WG (ipsec@ietf.org)" Thread-Topic: New Version Notification for draft-amjads-ipsecme-ikev2-data-channel-01.txt Thread-Index: AQHPPeiO1qUsOYKQVUCWirQNN+fFNJren44AgDhRGQCAExQE0IAAfquggChreXCAAeB1UIAC0c+A Date: Thu, 29 May 2014 07:35:37 +0000 Message-ID: <62922D1DB814EF458679925ECD8AA68D242D8CA0@xmb-rcd-x10.cisco.com> References: <20140312114328.20101.44457.idtracker@ietfa.amsl.com> <8D3D17ACE214DC429325B2B98F3AE712076C2EC424@MX15A.corp.emc.com> <62922D1DB814EF458679925ECD8AA68D242A33ED@xmb-rcd-x10.cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076C43817A@MX15A.corp.emc.com> <62922D1DB814EF458679925ECD8AA68D242D244C@xmb-rcd-x10.cisco.com> <8D3D17ACE214DC429325B2B98F3AE712076C66300C@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C66300C@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.46.97] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ForqI8O5-kgE5MWHlBu50X4pGbI Subject: Re: [IPsec] New Version Notification for draft-amjads-ipsecme-ikev2-data-channel-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 07:35:44 -0000 Hi David, Thanks for the detailed reply.=20 Joe's comments below on lack of congestion control and small traffic load w= ere specifically for the 'acknowledged data transfer mode' (draft-0) that l= everaged IKEv2's exchange structure and windowing mechanism.=20 Based on the comments, the updated draft (draft-1) deprecated 'acknowledged= data transfer mode' and only uses 'un-acknowledged/unreliable data transfe= r mode' that does not use IKEv2's exchange structure and windowing mechanis= m and is very similar to IPSec ESP. Hence the comments do not apply to the = new draft and IKEv2 data channel provides similar service as DTLS and IPSec= -ESP/UDP (NAT-T). Thanks, -Amjad -----Original Message----- From: Black, David [mailto:david.black@emc.com]=20 Sent: Tuesday, May 27, 2014 5:51 PM To: Amjad Inamdar (amjads); IPsecme WG (ipsec@ietf.org) Subject: RE: New Version Notification for draft-amjads-ipsecme-ikev2-data-c= hannel-01.txt Hi Amjad, > I glanced through RFC 5405 and I think the unacknowledged UDP based=20 > data transfer provided by IKEv2 data channel is similar to DTLS and=20 > IPSec-over-UDP (used with NAT-T). Please let me know if I am missing anyt= hing here. Sure, Joe originally wrote: > This mechanism lacks congestion control, and so needs to be used only=20 > where its load is known to be a small fraction of capacity. In=20 > specific, IKE's window mechanism allows for increasing the window size=20 > but not decreasing it, as is needed to react to network congestion. >=20 > The acknowledged data transfer mode uses IKE's window mechanism, which=20 > is presumably set to a small value, and may result in very low throughput= . > Attempts to increase this window size to overcome this limitation can=20 > easily increase burstiness and network loss. I believe both comments continue to apply. IKEv2 is self-limiting in its u= se of UDP courtesy of IKEv2's exchange structure; this draft proposes to ch= ange that. If the intended use case really is IoT, then something can be s= aid about the limited amount/rate of traffic that is involved. Thanks, --David > -----Original Message----- > From: Amjad Inamdar (amjads) [mailto:amjads@cisco.com] > Sent: Monday, May 26, 2014 3:37 AM > To: Black, David; Rajeshwar Singh Jenwar (rsj); IPsecme WG=20 > (ipsec@ietf.org) > Subject: RE: New Version Notification for=20 > draft-amjads-ipsecme-ikev2-data- channel-01.txt >=20 > Hi David, >=20 > I glanced through RFC 5405 and I think the unacknowledged UDP based=20 > data transfer provided by IKEv2 data channel is similar to DTLS and=20 > IPSec-over-UDP (used with NAT-T). Please let me know if I am missing anyt= hing here. >=20 > Thanks, > -Amjad >=20 > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Wednesday, April 30, 2014 7:53 PM > To: Amjad Inamdar (amjads); Rajeshwar Singh Jenwar (rsj); IPsecme WG > (ipsec@ietf.org) > Subject: RE: New Version Notification for=20 > draft-amjads-ipsecme-ikev2-data- channel-01.txt >=20 > Amjad, >=20 > I'm sorry, but that would be incorrect; please read RFC 5405 and apply=20 > its design guidance. >=20 > Thanks, > --David (Transport Directorate member and tsvwg WG co-chair) >=20 > > -----Original Message----- > > From: Amjad Inamdar (amjads) [mailto:amjads@cisco.com] > > Sent: Wednesday, April 30, 2014 2:52 AM > > To: Black, David; Rajeshwar Singh Jenwar (rsj); IPsecme WG > > (ipsec@ietf.org) > > Subject: RE: New Version Notification for > > draft-amjads-ipsecme-ikev2-data- channel-01.txt > > > > Hi David, > > > > In the new version (version 1) of the draft, unlike IKEv2 control=20 > > packets the data packets are not acknowledged and hence the comments=20 > > on congestion and windowing no longer apply. > > > > Thanks, > > -Amjad > > > > -----Original Message----- > > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Black,=20 > > David > > Sent: Friday, April 18, 2014 3:58 AM > > To: Rajeshwar Singh Jenwar (rsj); IPsecme WG (ipsec@ietf.org) > > Subject: Re: [IPsec] New Version Notification for > > draft-amjads-ipsecme-ikev2- data-channel-01.txt > > > > Well, Joe Touch's comments on congestion still apply: > > > > http://www.ietf.org/mail-archive/web/ipsec/current/msg08654.html > > > > I suggest consulting RFC 5405 on this topic, and applying its guidance. > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Rajeshwar=20 > > > Singh Jenwar (rsj) > > > Sent: Wednesday, March 12, 2014 10:27 PM > > > To: IPsecme WG (ipsec@ietf.org) > > > Subject: [IPsec] FW: New Version Notification for > > > draft-amjads-ipsecme-ikev2- data-channel-01.txt > > > > > > Hi, > > > > > > We (Amjad and I) have published new version of "Data over IKEv2=20 > > > for application security" draft based on inputs/comments received. > > > Please review and provide comments/inputs/questions. > > > > > > Kind Regards, > > > Raj > > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > Sent: Wednesday, March 12, 2014 5:13 PM > > > To: Amjad Inamdar (amjads); Rajeshwar Singh Jenwar (rsj);=20 > > > Rajeshwar Singh Jenwar (rsj); Amjad Inamdar (amjads) > > > Subject: New Version Notification for > > > draft-amjads-ipsecme-ikev2-data-channel- > > > 01.txt > > > > > > > > > A new version of I-D,=20 > > > draft-amjads-ipsecme-ikev2-data-channel-01.txt > > > has been successfully submitted by Amjad S. Inamdar and posted to=20 > > > the IETF repository. > > > > > > Name: draft-amjads-ipsecme-ikev2-data-channel > > > Revision: 01 > > > Title: IKEv2 based lightweight secure data communication draft- > > > amjads-ipsecme-ikev2-data-channel-01 (D-IKE) > > > Document date: 2014-03-12 > > > Group: Individual Submission > > > Pages: 15 > > > URL: http://www.ietf.org/internet-drafts/draft-amjads-ipse= cme- > ikev2-data-channel-01.txt > > > Status: https://datatracker.ietf.org/doc/draft-amjads-ipsecme= - > ikev2- > > > data-channel/ > > > Htmlized: http://tools.ietf.org/html/draft-amjads-ipsecme-ikev2= - > data- > > > channel-01 > > > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-amjads-ipsec= me- > ikev2- > > > data-channel-01 > > > > > > Abstract: > > > The Internet Key Exchange (IKEv2) protocol provides authentication= , > > > confidentiality, integrity, data-origin authentication and anti- > > > replay. Currently, IKEv2 is mainly used as a control channel to > > > negotiate IPsec SA(s). IPsec is not well suited to provide transp= ort > > > layer security for applications as it resides at the network layer > > > and most of the IPsec implementations require integration into > > > operating systems making it difficult to deploy. IPsec uses > > > different sessions for control and data traffic which is not NAT a= nd > > > load balancer friendly. TLS/DTLS, the other popular security > > > mechanism to provide the above security services does not mandate > > > mutual peer authentication and Diffie Hellman exchange. > > > > > > This document describes an IKEv2 based lightweight secure data > > > communication protocol and a way to provide transport layer securi= ty > > > for UDP client/server applications. The protocol provides integri= ty > > > protected encryption and integrity-only protection based on > > > application needs. As most of the IoT applications are UDP based, > > > IKEv2 can be used for key management as well secure data > > > communication in IoT due to its simplicity, scalability, > > > lightweightedness and ease of deployment. > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of=20 > > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > > > The IETF Secretariat > > > > > > _______________________________________________ > > > 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