Ahmad, I could be wrong but MOBIKE should technically allow the responder (SeGW here) to update the addresses in the IPsec SA. At least that is how I interpret the text in RFC4555 Section 3.5. Currently that is restricted to a single specific scenario, though (and this to work, would require SeGWs be able to share required SA information between each other using some mechanism).
- Jouni On May 5, 2014, at 7:29 PM, Ahmad Muhanna wrote: > Hello Jouni, > > If my understanding is correct, MOBIKE allows the client to move its IKE > tunnel from one SeGW to another based on Handover, for example. A multihoming > IKE, if I may say. > What Vijay is trying to address (at least this is my understanding) here is > the scenario from the other end. When the SeGW is overloaded and would like > to REDIRECT the client to another SeGW. The client won't know the condition > at the SeGW and the SeGW is the one who initiates the proposed move. > > Regards, > Ahmad > > > > On Mon, May 5, 2014 at 9:03 AM, Jouni <[email protected]> wrote: > > Just a thought.. would MOBIKE be any use here? At least one would be able to > move the SeGWs on fly (assuming the source and destination SeGW are able to > share required information between each other). > > - Jouni > > On May 5, 2014, at 3:45 PM, Ahmad Muhanna wrote: > > > Hi Vijay, > > > > Please see comments inline. > > > > On Mon, May 5, 2014 at 12:30 AM, vijay kn <[email protected]> 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:[email protected]] > > Sent: Sunday, May 04, 2014 9:41 PM > > To: vijay kn > > Cc: [email protected]; [email protected]; [email protected]; > > [email protected] > > 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 <[email protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > -- > > Regards, > > Ahmad > > _______________________________________________ > > IPsec mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > -- > Regards, > Ahmad _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
