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

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 <praveenys@juniper.net<mailto: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 <vijay.kn@huawei.com<mailto:vijay.kn@huawei.com>>
Date: Sunday, May 4, 2014 at 10:30 PM
To: Ahmad Muhanna <asmuhanna@gmail.com<mailto:asmuhanna@gmail.com>>
Cc: "ipsec@ietf.org<mailto:ipsec@ietf.org>" <ipsec@ietf.org<mailto:ipsec@ietf.org>>, "vijay@wichorus.com<mailto:vijay@wichorus.com>" <vijay@wichorus.com<mailto:vijay@wichorus.com>>, "kilian.weniger@googlemail.com<mailto:kilian.weniger@googlemail.com>" <kilian.weniger@googlemail.com<mailto:kilian.weniger@googlemail.com>>, "vjkumar2003@gmail.com<mailto:vjkumar2003@gmail.com>" <vjkumar2003@gmail.com<mailto: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<mailto:vijay@wichorus.com>; kilian.weniger@googlemail.com<mailto:kilian.weniger@googlemail.com>; ipsec@ietf.org<mailto:ipsec@ietf.org>; vjkumar2003@gmail.com<mailto: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<mailto: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<mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec

--
Regards,
Ahmad