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

Yoav Nir <ynir.ietf@gmail.com> Sun, 04 May 2014 07:26 UTC

Return-Path: <ynir.ietf@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 EC4B91A0175 for <ipsec@ietfa.amsl.com>; 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 <ipsec@ietfa.amsl.com>; 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 <ipsec@ietf.org>; Sun, 4 May 2014 00:26:20 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id n15so1415279wiw.14 for <ipsec@ietf.org>; 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 <multiple recipients> (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 <ynir.ietf@gmail.com>
In-Reply-To: <AD5AD8B0B070044BAD3C37D7057F37E153FE638D@szxeml513-mbx.china.huawei.com>
Date: Sun, 04 May 2014 10:26:15 +0300
Message-Id: <22DBA0CE-BF37-48E2-A87D-B1D66E64DE1B@gmail.com>
References: <AD5AD8B0B070044BAD3C37D7057F37E153FE638D@szxeml513-mbx.china.huawei.com>
To: vijay kn <vijay.kn@huawei.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/oAnKMJBeNmQG_FLp7YAjage0kss
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 07:26:24 -0000

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

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