Re: Comments/questions about the assumptions [Was: Re: Revised proposed BOF charter, problem statement, and agenda]

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

2007/3/7, Narayanan, Vidya <vidyan@xxxxxxxxxxxx>:
> In addition to what Paul has said, there is one more point. In the case
> of solutions that are transparent to the client,  there may be one
> gateway that is actively serving as a "primary" gateway and one or more
> gateways acting as "backup" gateways; one of the backup gateways takes
> over for the primary (i.e., assumes the IP address of the primary and
> acquires all the clients that were being served by the primary) when the
> primary gateway fails. This essentially leads to the situation where all
> these gateways are capable of serving the same set of subnets (i.e.,
> have associations with the same DHCP servers) and hence, more or less
> restricts the geographic distribution of these gateways.

I don't agree with this conclusion: if I take again my example of
solution based on MIPv6, the "real" IP addresses of the SGs are the
CoA and the SGs may be distributed in a large scale.

> The other problem space is one where the gateways are all active and
> distributed and serving clients of their own - upon failure of one
> gateway, the clients being served by that gateway may connect to a
> different gateway within the same secure domain

By the way, I think it would be useful to have a clear definition of a
secure domain. IIRC, there is no definition of it in the PS draft.

> . In this case, it is not
> feasible for these gateways to have the same IP address or serve the
> same set of subnets and hence, transparency to the client is not
> feasible.

Again, I don't agree on your conclusion.
And again based on my example of solution based on MIPv6, all the SGs
has a same and common IP address, the HoA.
Now, maybe, there are others solutions that I don't know allowing the
same features :)

Best regards.

JMC.

> This scenario allows for having functional gateways that may
> be serving various sites also be "backup" gateways for other gateways in
> the domain. In situations like massive network failures that take down
> an entire site or various Mobile IP home agents (that use IPsec) that
> the clients may attach to within the secure domain, there is a need for
> a quick failover that doesn't involve re-establishment of the entire SA,
> including client authentication and DH exchange, etc.
>
> Hope that helps.
>
> Regards,
> Vidya
>
> > -----Original Message-----
> > From: owner-ietf-ipsec-failover@xxxxxxxxxxxxx
> > [mailto:owner-ietf-ipsec-failover@xxxxxxxxxxxxx] On Behalf Of
> > Paul Hoffman
> > Sent: Tuesday, March 06, 2007 1:53 PM
> > To: ietf-ipsec-failover@xxxxxxxx
> > Subject: Re: Comments/questions about the assumptions [Was:
> > Re: Revised proposed BOF charter, problem statement, and agenda]
> >
> >
> > At 3:28 PM -0500 3/6/07, Wesley Eddy wrote:
> > >I know of environments that need client-transparent solutions.  Are
> > >there really cases where a client-based solution is favorable to a
> > >client-transparent solution?
> >
> >  From our pre-list discussions, it seems that the answer is
> > "yes" *if* the only thing the client needs to do is update
> > its address but not re-authenticate. A fully-transparent
> > solution requires that all gateways communicate about which
> > addresses are already handed out (and possibly to whom they
> > were handed), which puts a significant burden on the
> > intra-gateway communication system.
> >
> > >  It sure seems like most admins would like to have their servers
> > >figure out how to do any failover, load-balancing, etc. and hide all
> > >that from the clients, but maybe the perspective from my niche is
> > >skewed.
> >
> > Of course that would be nice, but it also has to be
> > completely reliable. The last thing you want is for the
> > client to connect to the failed-to gateway and have the
> > gateway say "go away, someone else is using the address you
> > think is yours". It is much better for the gateway to be able
> > to, in a DHCP-like fashion, say "hi there, here's your new
> > address" or, even better, "hi there, your current address looks fine".
> >
> > --Paul Hoffman, Director
> > --VPN Consortium
> >
> >