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

From: vijay kn <[email-masked]>
Date: Fri, 2 May 2014 14:14:30 +0000

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.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 4 May 2014 10:26:15 +0300

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 <[email-masked]> wrote:

> 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)
> “”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: -
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Ahmad Muhanna <[email-masked]>
Date: Sun, 4 May 2014 11:10:49 -0500

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-masked]> wrote:
> 
> Hi,

---

From: vijay kn <[email-masked]>
Date: Mon, 5 May 2014 04:08:50 +0000

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

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.

Thanks.

From: IPsec [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Sunday, May 04, 2014 12:56 PM
To: vijay kn
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
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?

Yoav

On May 2, 2014, at 5:14 PM, vijay kn <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Scenario: -

Effect/Impact: -

Suggestion/Solution: -

Request for comments: -

Regards,
Vijay N.

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

---

From: vijay kn <[email-masked]>
Date: Mon, 5 May 2014 05:30:03 +0000

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:[email-masked]]
Sent: Sunday, May 04, 2014 9:41 PM
To: vijay kn
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685)

Hi, Vijay,

Regards,
Ahmad Muhanna

On May 2, 2014, at 9:14 AM, vijay kn <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
There is an issue in IKEv2 REDIRECT RFC 5685. In one scenario, the IKEv2 REDIRECT will not work indefinitely.

Scenario: -

Effect/Impact: -

Suggestion/Solution: -

Request for comments: -

Regards,
Vijay N.

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 5 May 2014 10:07:19 +0400

Hi Vijay,

  ----- Original Message ----- 
  From: vijay kn 
  To: Yoav Nir 
  Cc: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Monday, May 05, 2014 8:08 AM
  Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685)

  Hi Yoav,

If you upgrade software, you will need to reestablish all IKE SAs in any case.

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.

  Hi Vijay

  Yoav

  Hi,

  Scenario: -

  IKE_SA_INIT message)

  Effect/Impact: -

  Suggestion/Solution: -

  Request for comments: -

   

  Regards,

  Vijay N.

------------------------------------------------------------------------------

---

From: Ahmad Muhanna <[email-masked]>
Date: Mon, 5 May 2014 07:45:02 -0500

Hi Vijay,

Please see comments inline.

On Mon, May 5, 2014 at 12:30 AM, vijay kn <[email-masked]> 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.
>
>
>
> *From:* Ahmad Muhanna [mailto:[email-masked]]
> *Sent:* Sunday, May 04, 2014 9:41 PM
> *To:* vijay kn
> *Cc:* [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> *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.
>
>
>
> *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: -*
>
> ""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.
>
>
>

-- 
Regards,
Ahmad

---

From: Jouni <[email-masked]>
Date: Mon, 5 May 2014 17:03:14 +0300

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:

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

---

From: Ahmad Muhanna <[email-masked]>
Date: Mon, 5 May 2014 11:29:01 -0500

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-masked]> 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
>
> > 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
> > 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
> > 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
> 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
> > 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: -
> >
> > ""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.
> >
> >
> >

-- 
Regards,
Ahmad

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Mon, 5 May 2014 17:05:49 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Sunday, May 4, 2014 at 10:30 PM
To: Ahmad Muhanna <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685)

Hi Ahmad,

Recommendation: -

From: Ahmad Muhanna [mailto:[email-masked]]
Sent: Sunday, May 04, 2014 9:41 PM
To: vijay kn
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685)

Hi, Vijay,

Regards,
Ahmad Muhanna

Scenario: -

Effect/Impact: -

Suggestion/Solution: -

Request for comments: -

Regards,
Vijay N.

---

From: Ahmad Muhanna <[email-masked]>
Date: Mon, 5 May 2014 12:17:54 -0500

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 <
[email-masked]> wrote:

>    REKEY_SA Notify payloads), and *finally deleting the old IKE SA* (which
>   From: vijay kn <[email-masked]>
> To: Ahmad Muhanna <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> *From:* Ahmad Muhanna [mailto:[email-masked] <[email-masked]>]

-- 
Regards,
Ahmad

---

From: Jouni <[email-masked]>
Date: Mon, 5 May 2014 23:51:08 +0300

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

---

From: Ahmad Muhanna <[email-masked]>
Date: Mon, 5 May 2014 17:17:35 -0500

Hello Jouni,

I see what you are saying but that is still a stretch :)
As per section 3.5, the following is the relative text:

   There is one exception to the rule that the responder never updates
   any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request.  If
   the source address that the responder is currently using becomes
   unavailable (i.e., sending packets using that source address is no
   longer possible), the responder is allowed to update the IPsec SAs to
   use some other address (in addition to initiating the procedure
   described in the next section).

I guess this text is very powerful and at the same time what we have
currently is a little different than the IP address of the SeGW
becoming unavailable.

At any rate: IMO, I believe that Re-authentication as listed in
RFC5996 and as pointed out by Praveen is the correct approach.

Regards,

Ahmad

On Mon, May 5, 2014 at 3:51 PM, Jouni <[email-masked]> wrote:

>
> 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
>
> > 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
> >
> >
> >
> > 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
> >
> > > 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
> > >
> > > 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.
> > >
> > > Since the base stations normally establish Tunnel with other vendor
> base stations and/or other vendor Gateways which may or may not support
> > > 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
> > > 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

-- 
Regards,
Ahmad

---

From: vijay kn <[email-masked]>
Date: Tue, 6 May 2014 03:45:36 +0000

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:[email-masked]]
Sent: Monday, May 05, 2014 10:48 PM
To: Praveen Sathyanarayan
Cc: vijay kn; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [IPsec] Regarding IKEv2 REDIRECT problem (reference RFC 5685)

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 <[email-masked]<mailto:[email-masked]>> wrote:
Why not trigger Re-authentication from base station, when upgraded/REDIRECT enabled in config?

RFC 5996:

Thanks,
Praveen

Hi Ahmad,

Recommendation: -

Hi, Vijay,

Regards,
Ahmad Muhanna

Scenario: -

Effect/Impact: -

Suggestion/Solution: -

Request for comments: -

Regards,
Vijay N.

--
Regards,
Ahmad

---

From: Ahmad Muhanna <[email-masked]>
Date: Mon, 5 May 2014 23:18:11 -0500

Hello Vijay,

No one is trying to deviate from the original topic. Let me try to address what you just mentioned one more time.

You just mentioned that some vendors do not support Reauth. But let me remind you; no vendor is supporting what you are proposing now. How that becomes an argument.

On the other hand, I provided you with an example that your proposal will NOT solve; while the SeGW even support REDIRECTION as per RFC5685 already; you some how chose to ignore it. Here is the text for the reminder:
"
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.
"

Regards,
Ahmad

> On May 5, 2014, at 10:45 PM, vijay kn <[email-masked]> wrote:
> 
> Praveen/Ahmad,
> Some vendors don’t support Reauth. In this case what to do?
> On Mon, May 5, 2014 at 12:05 PM, Praveen Sathyanarayan <[email-masked]> wrote:
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 6 May 2014 16:13:33 +0300

vijay kn writes:
> Praveen/Ahmad,> Some vendors don’t support Reauth. In this case what
> to do? 

There is no specific need for reauth on the protocol level. You create
new IKE SA, you create new Child SAs, you delete old IKE SA.
Everything is just standard IKEv2 and all implementations support
that on the protocol level. For the SGW end everything looks like the
client just reconnected.

For the client end you need bit more code. I.e. when client notices
that policy has changed so that REDIRECT support should be turned,
then instead of sending your new INFORMATIONAL exchange, it will
simply do the reauthentication.

This is much easier to implement than what you suggested. Also as
people have already pointed out, there is NO POINT of disabling
feature on the implementations, especially if you can already now see
that you might need it at some point. If it cause problems because of
bugs, fix those bugs. If the client implemenation does not support
REDIRECT, then upgrade it, and upgrade usually means that you need to
start IKE SA again anyways...

> I think we are slightly deviating from our original topic.

I do not think there is problem here that requires solving. We already
have REDIRECT. There are ways to use it. There is way to enable it by
doing reauthentication. There is actually another way to do the same
thing, i.e. using MOBIKE to dynamically move SAs from one IP-address
to another, and of you support suitable methods of transfering SA
information to another host you can use that to move all or some IKE
and IPsec SAs from one host to another without causing any
disruptions. On the other hand you need to send MOBIKE_SUPPORTED in
IKE_AUTH, so you cannot enable that on the fly either... And one of
the use cases in RFC4621 (MOBIKE Design document) is multihomed
servers, i.e. the MOBIKE do allow both ends to move. The rendezvous
is outside the scope of MOBIKE, so both ends cannot move at the same
time without keeping at least some of the addresses intact.

> Why to do reauth which is an expensive operation when you can just intimate
> the SeGW that u support redirect via an INFO msg.

If you do not want to do expensive operations, then enable the
REDIRECT support from the beginning... 
-- 
[email-masked]