Hi Vijay, ----- Original Message ----- From: vijay kn To: Yoav Nir Cc: ipsec@ietf.org ; vi...@wichorus.com ; kilian.weni...@googlemail.com ; vjkumar2...@gmail.com Sent: Monday, May 05, 2014 8:08 AM Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685)
Hi Yoav, Yes your understanding is right. They are disabled by configuration but later enabled may be after tunnel is setup. FYI, it has no relation with roaming. I can see this as a case like: 1) When a base station is initially not REDIRECT enabled but later the software version is upgraded to the version that has REDIRECT support If you upgrade software, you will need to reestablish all IKE SAs in any case. 2) The base station normally will be REDIRECT disabled because the base station might establish Tunnel with other base stations and/or other SeGWs which may or may not support REDIRECT. So the config will be disabled by default. Sorry, I don't see the reason to have REDIRECT disabled by default if you support it. You may safely always offer support for it. If peer is SecGW and also supports it, you will have it negotiated and then it may be used it in any time. Otherwise peer will just not return REDIRECT_SUPPORTED notification and you will live without it. The only reason to have REDIRECT disabled that I can imagine of is situation, when your peer's implementation is broken and doesn't ignore unknown status notification, but instead, for example, crashes . I don't think this reason justifies changing RFC. Note, that RFC5723 is not the only IKE extension RFC that have feature support negotiation during establishing of IKE SA. The same is true for RFC4555 (MOBIKE) and RFC6311 (support for HA). This is common practice for IKE extensions to be negotiated during IKE SA establishment. Regards, Valery Smyslov. Thanks. From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir Sent: Sunday, May 04, 2014 12:56 PM To: vijay kn Cc: ipsec@ietf.org; vi...@wichorus.com; kilian.weni...@googlemail.com; vjkumar2...@gmail.com Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685) 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...@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 ------------------------------------------------------------------------------ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
