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

Ahmad Muhanna <asmuhanna@gmail.com> Mon, 05 May 2014 12:45 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 C309F1A0079 for <ipsec@ietfa.amsl.com>; 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 <ipsec@ietfa.amsl.com>; 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 <ipsec@ietf.org>; Mon, 5 May 2014 05:45:06 -0700 (PDT)
Received: by mail-qg0-f50.google.com with SMTP id z60so2295545qgd.9 for <ipsec@ietf.org>; 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: <AD5AD8B0B070044BAD3C37D7057F37E153FE64F9@szxeml513-mbx.china.huawei.com>
References: <AD5AD8B0B070044BAD3C37D7057F37E153FE638D@szxeml513-mbx.china.huawei.com> <E1DF8B79-5C70-43EF-AA52-1F13F1A77C7B@gmail.com> <AD5AD8B0B070044BAD3C37D7057F37E153FE64F9@szxeml513-mbx.china.huawei.com>
Date: Mon, 05 May 2014 07:45:02 -0500
Message-ID: <CAPfd2wPyOgMAWGzwo2Aepxn09-_fvrMzBc=sTfLafbp+yWMSPg@mail.gmail.com>
From: Ahmad Muhanna <asmuhanna@gmail.com>
To: vijay kn <vijay.kn@huawei.com>
Content-Type: multipart/alternative; boundary="001a11c15f3a03934304f8a68014"
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/eSwpp9rWEu8UPQasOX8bD3IkZu4
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, "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: Mon, 05 May 2014 12:45:10 -0000

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


-- 
Regards,
Ahmad