Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685)

Ahmad Muhanna <asmuhanna@gmail.com> Sun, 04 May 2014 16:10 UTC

Return-Path: <asmuhanna@gmail.com>
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 <ipsec@ietfa.amsl.com>; 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 <ipsec@ietfa.amsl.com>; 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 <ipsec@ietf.org>; Sun, 4 May 2014 09:10:53 -0700 (PDT)
Received: by mail-ig0-f172.google.com with SMTP id uy17so3780925igb.5 for <ipsec@ietf.org>; 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 <multiple recipients> (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 <asmuhanna@gmail.com>
X-Mailer: iPhone Mail (11D201)
In-Reply-To: <AD5AD8B0B070044BAD3C37D7057F37E153FE638D@szxeml513-mbx.china.huawei.com>
Date: Sun, 04 May 2014 11:10:49 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <E1DF8B79-5C70-43EF-AA52-1F13F1A77C7B@gmail.com>
References: <AD5AD8B0B070044BAD3C37D7057F37E153FE638D@szxeml513-mbx.china.huawei.com>
To: vijay kn <vijay.kn@huawei.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/fBGS56ImRlTH0MFFpBbext1WZw0
Cc: "ipsec@ietf.org" <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)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 May 2014 16:10:56 -0000

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 <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’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