Re: Regarding IKEv2 REDIRECT problem (reference RFC 5685)
Yoav Nir <ynir.ietf@gmail.com> Fri, 02 May 2014 13:30 UTC
Return-Path: <ynir.ietf@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C149C1A6FBC for <ietf@ietfa.amsl.com>; Fri, 2 May 2014 06:30:47 -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 tXqm2f3J6kMz for <ietf@ietfa.amsl.com>; Fri, 2 May 2014 06:30:45 -0700 (PDT)
Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 75B9D1A6FC8 for <ietf@ietf.org>; Fri, 2 May 2014 06:30:45 -0700 (PDT)
Received: by mail-we0-f175.google.com with SMTP id q58so4479889wes.6 for <ietf@ietf.org>; Fri, 02 May 2014 06:30:42 -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=ded3NNTIFKBYxS67HE0cn/PDMkRiy4ZOUiPteBxAdUs=; b=JXDF75aRNPCyiMWjC+h19JG04QBg/oVT8UhttELtxAX0EKMhRrR6QA5BY027OX3plI MdUYzNa0l9RJYILjagDQwRJISmQlgiw/GBZ7NRSXRzMEEGQcLii6d3LLrFwWNuprsWMU 5Ys+YmSFjuteAShGbz/gtC3HMbkQUaU5d6Ko0YOS011hK2h9nAGgAKwi10p1SNx5cLfP rpTdfgozNbcYqtLw2q2Vacc5rLkL5amfyJVShLb0/AWvl6ToQ8M4eVduaCJH668MMr0r BaKCdkg9PsZuvbqnOFBmIUN2r30jJva3c6yYi2/4QwHRSEjaHiqIlGksacRHqYv9EveH ymfg==
X-Received: by 10.194.171.198 with SMTP id aw6mr13942634wjc.23.1399037442758; Fri, 02 May 2014 06:30:42 -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 pl6sm2203847wjc.0.2014.05.02.06.30.41 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 May 2014 06:30:42 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_568F0C57-E709-421C-8B06-AD77B7AC961B"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: Re: Regarding IKEv2 REDIRECT problem (reference RFC 5685)
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <AD5AD8B0B070044BAD3C37D7057F37E153FE6351@szxeml513-mbx.china.huawei.com>
Date: Fri, 02 May 2014 16:30:39 +0300
Message-Id: <7BC50EAE-3DBA-4A5C-A1FD-F6A8470FB77D@gmail.com>
References: <AD5AD8B0B070044BAD3C37D7057F37E153FE6351@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/ietf/hMc08deiCYK5P2X7214IfhgQKaI
Cc: "vijay@wichorus.com" <vijay@wichorus.com>, "kilian.weniger@googlemail.com" <kilian.weniger@googlemail.com>, "ietf@ietf.org" <ietf@ietf.org>, "vjkumar2003@gmail.com" <vjkumar2003@gmail.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 May 2014 13:30:47 -0000
Hi, Vijay This issue is better addressed to the IPsec mailing list - ipsec@ietf.org (you need to register first at https://www.ietf.org/mailman/listinfo/ipsec ) This mailing list is mostly for administrative stuff and for discussing last call comments about drafts about to be published as RFCs. Yoav On May 2, 2014, at 4:19 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.