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

RE: Heartbeats draft available

Hi Scott,

For your sake, I'll present a list of requirements on Thursday. But don't be
surprised if they are very similar to the goals of the draft.

Negotiation is not a requirement of IPsec heartbeats; it is a requirement of
good protocol design. If there are options, or if there is any possibility
of needing options in the future, there should be negotiation.

BTW, Tero and I discussed heartbeat usage scenarios on the IPSRA list back
in November. Please see the attached message.

Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.


> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Scott G. Kelly
> Sent: Thursday, March 23, 2000 12:22 PM
> To: akrywani@newbridge.com
> Cc: 'Tero Kivinen'; 'Ricky Charlet'; ipsec@lists.tislabs.com
> Subject: Re: Heartbeats draft available
>
>
> akrywani@newbridge.com wrote:
> >
> <trimmed...>
>
> > In fact, I investigated using other negotiation protocols
> for heartbeat
> > configuration for the simple reason that I knew that using
> ISAKMP-Config as
> > transport would result in a silly, straw-man (or rather
> straw-protocol)
> > political argument such as this one.
>
> Again, this misses the point: you have to explicitly specify the
> requirements, because otherwise it is not clear that negotiation is
> required. Only when we understand *why* negotiation is required can we
> intelligently discuss protocol requirements.
>
> Scott
>

-- BEGIN included message

> 	1) Clean up the gateway SAs after the client disappears
> 	   because of the dialup-link broke down.
> 	2) Switch to next gateway in the gateway host list in case the
> 	   gateway is not respoding anymore.
> 	3) Check that other ends IKE daemon is still up and working.
> 	4) Detect network connection losses ASAP so they can be
> 	   reported to the user.
> 	5) Detect when the other end is crashed, and when we should
> 	   try to recreate our SAs to it

Hi Tero,

That's a pretty good requirements analysis.

I say... we should support all of them.

But basically this comes down to two categories:

Detection:

1) Detect when the box is missing (it rebooted, the remote user hung up, the
daemon is broken, the network is down).
2) Detect when the IPSec SA is missing (DELETE was lost, keymat out of
synch, whatever).

Resolution:

1) Cleanup memory.
2) Re-establish sa.
3) Notify user.
4) Re-route traffic.

Note that most of these actions require that there be a logical distinction
between clients and sgws. Currently, we do not have such a distinction. We
would have to guess that the peer is a client:

1) because it uses an ipsra-specific protocol.
2) because it uses an id that is known to be a client id.

Andrew
_______________________________________________
 Beauty without truth is insubstantial.
 Truth without beauty is unbearable.

-- END included message

Follow-Ups: References: