Re: [IPsec] question about IKEv2 Re-direct
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IPsec] question about IKEv2 Re-direct



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: ipsec-bounces at ietf.org [mailto:ipsec-bounces at ietf.org] On Behalf Of
> Vijay Devarapalli
> Sent: Wednesday, February 04, 2009 2:59
> To: Richard Graveman
> Cc: ipsec at ietf.org
> Subject: Re: [IPsec] question about IKEv2 Re-direct
>
> Hello,
>
> On Tue, Feb 3, 2009 at 2:45 PM, Richard Graveman <rfgraveman at gmail.com>
> wrote:
> > Hi,
> >
> >> On Tue, Feb 3, 2009 at 9:06 AM, Richard Graveman <rfgraveman at gmail.com>
> wrote:
> >>> 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?
> >>
> >> 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.]
>
> 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
> _______________________________________________
> IPsec mailing list
> IPsec at ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.
>
> Scanned by Check Point Total Security Gateway.

Email secured by Check Point

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.