[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Heartbeats draft (fwd)

On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote:
> I am not saying that we should totally ingnore this case, and I proposed
> an alternative approach. What I am saying is that we don't have to make
> IKE suite of protocols so chatty, just to handle conditions like "server
> crashed", or "someone accidentaly switched the server off" etc. Such
> chatty approaches to the problem are not very desirable in dialup
> scenarios anyway, and I guess dialup is a significant protion of the
> deployment.
> 
I personally don't believe that. A portion, yes. How significant remains to
be seen, given the advent of DSL and cable-modems, which are always on.

I've already pointed out to Andrew that his scheme doesn't work well in
ISDN/analog dial-up scenarios anyway, where you pay per-minute charges and
heartbeats would keep the line up.

In the interest of standardizing on at least ONE approach, I'm willing to
sacrifice that. Afterall, I can define a new keepalive-type in Andrew's
configuration scheme and write a draft about the dial-up-specific keepalives,
and I'm on my way, and I'm not impeding the progress of at least ONE
standardized keepalives.

Also, a client that is behind a dial-up line, can simply refuse to do
heartbeats during negotiation, and you're still no worse off.

It can't solve EVERY problem in the universe. Let's let it solve the majority
of the problems, and other cases we'll find other solutions for.

> So, by heartbeats you are trying to have an expensive solution to a rarely
> occuring problem ("peer going down"), and the solution may not be suitable
> for most of the deployments (dialup).
> 
Again assuming that 'most' is correct in the paragraph above, which I
disagree with.

jan



> -chinna
> 
> On Tue, 28 Mar 2000, Jan Vilhuber wrote:
> 
> > On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote:
> > > Realistically how often does a server reboot? If the server is rebooting
> > > too often, then I guess we would be much better off, if we fixed the
> > > server, instead of trying to handle this scenario as if it is such a
> > > common scenario in IPSec.
> > 
> > In an ideal world, yes. Now in the REAL world, we do have to worry about
> > these things.
> > 
> > jan
> > 
> > 
> > > -chinna
> > > 
> > > On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote:
> > > 
> > > > An invalid SPI error can be the trigger point (along with other carefully
> > > > selected conditions). The peer that just came up will know the
> > > > tunnel/transport end point of the peer who is trying to send traffic, and
> > > > it can initiate a Main Mode SA to that endpoint. This peer should also
> > > > include the initial contact, so that the SADs can be sync'ed back again.
> > > > 
> > > > If there is some traffic originating on the side of the peer that went
> > > > down, then it has to initiate an SA negotiation anyway. An initial contact
> > > > will sync the SADs again.
> > > > -chinna
> > > > 
> > > > On Tue, 28 Mar 2000, Henry Spencer wrote:
> > > > 
> > > > > On Mon, 27 Mar 2000, chinna pellacuru wrote:
> > > > > > When one of the peer goes down, and comes back up, as I said before, the peer
> > > > > > that went down can ("intellegently") initiate fresh SAs with the Initial
> > > > > > Contact...
> > > > > 
> > > > > This assumes that the peer which went down is aware, when it comes back
> > > > > up, that it *should* initiate fresh SAs.  That is not necessarily true. 
> > > > > If it were, life would indeed be much simpler. 
> > > > > 
> > > > > In a world of fixed, static, pre-arranged VPN connections, each end can be
> > > > > told to re-initiate when it comes back up.  Unfortunately, many people
> > > > > wish to use IPSec in much more dynamic situations, where only one end may
> > > > > be aware of the immediate desire to send packets.  How does a rebooted
> > > > > server determine which of its potential clients it should re-initiate
> > > > > with?  It may not even know their IP addresses!
> > > > > 
> > > > >                                                           Henry Spencer
> > > > >                                                        henry@spsystems.net
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > chinna narasimha reddy pellacuru
> > > > s/w engineer
> > > > 
> > > > 
> > > 
> > > chinna narasimha reddy pellacuru
> > > s/w engineer
> > > 
> > > 
> > 
> >  --
> > Jan Vilhuber                                            vilhuber@cisco.com
> > Cisco Systems, San Jose                                     (408) 527-0847
> > 
> > 
> 
> chinna narasimha reddy pellacuru
> s/w engineer
> 

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847
References: