Re: FW: Request for review of IKEv2/IPsec failover solution draft

["Jean-Michel Combes" <jeanmichel.combes@xxxxxxxxx>]

Hi,

2007/12/6, Narayanan, Vidya <vidyan@xxxxxxxxxxxx>:
> Hi,
>
> >
> > I am not in Vancouver, but I second Kuntal's comments.
> > Multi-vendor interoperability is important to me (and my
> > customers)
>
> I actually agree that multi-vendor interoperability is important.  I
> wouldn't advocate that any network provider be tied to one vendor's
> gateways.  Having said that, there are two pieces to achieving that
> gateway interoperability.  One is a standardized ticket format that
> stores the IKEv2/IPsec SA.  That is already defined in the document.
>
> The second is what Jean-Michel brought up - which is to have a standard
> means of establishing an inter-gateway SA that is used to protect the
> ticket.  This is left out of scope in the document.  However, as
> Lakshminath pointed out earlier, standard means of establishing that SA
> are already available with mechanisms that have been defined at the IETF
> for group keying.  If people feel that it should be referenced or
> included in the solution document as a means to establishing that SA, we
> can discuss that.

I have a short discussion with Yaron and he told me that one of the
protocols specified in the MSEC WG should be usable for the management
of the keys in the IPsec FailOver proposal.
If, there would be references to this protocol in the IPsec-FO
proposal, that should solve my problem I think.

Best regards.

JMC.

>
> > and a gateway-to-gateway mode of operation is also
> > preferable to us due to long latencies and low bandwidth
> > between clients and gateways.
> >
>
> This is an unrelated point to gateway-gateway interoperability itself.
> And, this is a point that I don't understand.  During a failover, the
> most impacted entity is the new gateway, that is handling a large number
> of clients that need to be brought up in a short amount of time.  If the
> gateway is permanently mirroring state from another gateway, nothing
> really needs to be done.  In this case, the gateway switch is
> transparent to the client.  But, this involves deployment of redundant
> gateways that are not doing anything when the primary one is active.  If
> all the gateways are actively serving clients, the switch isn't
> transparent to the client.
>
> OTOH, if the gateway is not fully transparent to the client, there must
> be client-gateway communication so that the entities can mutually
> authenticate each other and resume the session.  In this case, a minimum
> 1RT exchange is needed between the client and gateway.  In this event,
> it also seems to make sense to just make that exchange be session
> resumption exchange.
>
> So, I'm missing how the client can be totally uninvolved when the
> gateway switch is not transparent to it.  Please let me know what it is
> I'm missing.
>
> Thanks,
> Vidya
>