Subject: Re: [IPsec] question about IKEv2 Re-direct

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 2 Feb 2009 11:43:49 -0800

Hi,

On Mon, Jan 12, 2009 at 5:13 AM, Richard Graveman <[email-masked]> wrote:
> Hi,
>
> I just read this draft and think your idea is useful. I have one
> question (please excuse me if it's been answered):

Its not been brought up before. But from the beginning the focus for
this draft has always been on IKEv2 client-gateway scenarios.

> Is there anything special about VPNs (or MIPv6) that limits the use of
> this? Could you just say "IKEv2 Initiator" instead of "VPN client" and
> "IKEv2 Responder" instead of "VPN Gateway" everywhere?

The mechanism proposed in the draft can be used between any IKEv2
initiator and responder without any changes to the protocol.

> I have uses for IKEv2 that are neither VPNs nor MIPv6 and could
> possibly benefit from this, but the terminology is somewhat
> constraining.

If you don't mind, can you share those use-cases/scenarios with us? I
can't imagine a scenario where a re-direct would be useful between two
IKEv2 peers.

Vijay

>
> Thanks, Rich Graveman
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Richard Graveman <[email-masked]>
Date: Tue, 3 Feb 2009 01:20:26 -0500

Hi Vijay,

Thanks for your reply.

> initiator and responder without any changes to the protocol.

Thanks for the clarification. I think this is worth saying.

> can't imagine a scenario where a re-direct would be useful between two

Sure. My "client" and "server" happen to be running a peer-to-peer
signaling protocol to handle GMPLS provisioning. It's a peer-to-peer
protocol, because sometimes you "get a phone call" as well as "make a
phone call." The "server" at the so-called Provider Edge (PE) has as
natural an application of redirect as the remote-access-VPN case
(planned downtime, load balancing, etc.)

Regards, Rich Graveman

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 3 Feb 2009 08:27:43 -0800

Hi,

> Thanks for the clarification. I think this is worth saying.

I added the following to the Introduction section.

   The Re-direct mechanism described in this document is mainly intended
   for use in client-gateway scenarios.  However, the mechanism can also
   be used between any two IKEv2 peers.  The IKEv2 responder can re-
   direct the initiator to another responder with no changes to the
   mechanism described in this document.

Is this sufficient?

Vijay

---

From: Richard Graveman <[email-masked]>
Date: Tue, 3 Feb 2009 12:06:45 -0500

Thanks. Your text is fine. The point was raised that we may not want
both parties redirecting at once. In your use cases, is it always the
IKEv2 responder that would redirect?

Rich

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 3 Feb 2009 13:46:05 -0800

Hi,

> IKEv2 responder that would redirect?

Yes. It is always the responder in the client-gateway scenarios.

Vijay

---

From: Richard Graveman <[email-masked]>
Date: Tue, 3 Feb 2009 17:45:20 -0500

Hi,

> Yes. It is always the responder in the client-gateway scenarios.

Then, perhaps consider: "If a responder wants to redirect and receives
a redirect request from the initiator, <SHOULD, MUST, whatever> ignore
the initiator's request. [The idea is that if this causes the
initiator to fail, well then, initiate again.]

Regards, Rich

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 3 Feb 2009 16:58:47 -0800

Hello,

> initiator to fail, well then, initiate again.]

I created a new section in the draft, since it was getting
complicated. :) Here is the text.

7.  Use of the Redirect Mechanism between IKEv2 Peers

   The Re-direct mechanism described in this document is mainly intended
   for use in client-gateway scenarios.  However, the mechanism can also
   be used between any two IKEv2 peers.  This is especially useful for
   IKEv2 sessions between two gateway peer routers.

   When used between a client and gateway, the re-direct procedure is
   always initiated by the gateway.  But when used between two IKEv2
   peers, either of the IKEv2 end points can initiate the re-direct
   message.  In order to prevent any race condition that might occur if
   both decide to re-direct at the same time, the responder MUST not
   respond to re-direct message from the initiator, if it has already
   decided to re-direct the initiator.

A temporary pre04 version of the draft is at
http://www.dvijay.com/ietf/internet-drafts/ipsec/draft-ietf-ipsecme-ikev2-redirect-04.txt

Vijay

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 5 Feb 2009 11:04:16 +0200

Also, REDIRECT_SUPPORTED needs to be sent by both peers if we want to enable this case. Otherwise, when the initiator wants to redirect its peer, it cannot know that the responder actually supports this capability.

Thanks,
        Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Vijay Devarapalli
> Sent: Wednesday, February 04, 2009 2:59
> To: Richard Graveman
> Cc: [email-masked]
> Subject: Re: [IPsec] question about IKEv2 Re-direct
>
> Hello,
>
> Scanned by Check Point Total Security Gateway.
>
> Scanned by Check Point Total Security Gateway.

Email secured by Check Point

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 9 Feb 2009 10:16:59 -0800

Hi,

> Also, REDIRECT_SUPPORTED needs to be sent by both peers if we want to enable this case. Otherwise, when the initiator wants to redirect its peer, it cannot know that the responder actually supports…

Agreed.

Vijay