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

Re: Heartbeats Straw Poll

[ CC list trimmed ]

Theodore Ts'o wrote:
> 
>    Date: Tue, 8 Aug 2000 00:48:36 -0400 (EDT)
>    From: Skip Booth <ebooth@cisco.com>
> 
>    The server cares because it has to do things like stop accounting (a
>    very important remote access function) and return IP addresses back
>    to the DHCP server or to it's local pool.  It is critical that the IP
>    addresses are returned ASAP after the client has disconnected so they
>    can be reused for the next client.
> 
> Neither of these (accounting and returning IP addresses to a DHCP pool)
> are IPSEC issues.  This is stuff you have to deal with even if you're
> not using IPSEC.  Hence, solving it with an IPSEC-specific solution
> seems like we're barking up the wrong tree.
> 
>                                                         - Ted

I disagree. We have another object layer on top of Phase 1 and 2 SA's
that defines sessions. A session persists across multiple Phase 1 and
Phase 2 rekeying events and only dies shortly after all Phase 1 and 
Phase 2 SA's expire and/or are deleted. I'm sure many other vendors,
especially in the remote access market, have a similar kind of object
in their implementation.

The point of keep-alive/make-dead/heartbeat proposals is to notify
this session layer that the underlying IPSEC 'connection' is dead. The
session layer can then generate accounting records, free IP addresses,
and possibly establish new SA's via a backup security gateway.

How would you have us know that a 'session' is dead without the use
of an IPSEC specific (or at least sanctioned) solution? The only
standards based solution today (that I'm aware of) is to run L2TP
with PPP echos over IPSEC. There has to be a lighter weight solution
than L2TP to notify a session management layer that the peer is gone.

IMHO, a heartbeat protocol should run over a dedicated transport mode
Phase 2 SA whose selector is specific to the heartbeat mechanism. I
would allocate a new UDP port number specifically for the heartbeat
mechanism just so it can distinguished from all other user data. An
IPSEC peer that wants keepalives just has to create this SA using a
standard quick mode exchange. A peer that _doesn't_ want to accept
the heart-beat protocol can deny the quick mode request via its SPD.

If both peers agree to create this SA then its presence triggers the
heartbeat protocol to periodically send and/or request/reply heartbeat
packets.

-Ben McCann

-- 
Ben McCann                              Indus River Networks
                                        31 Nagog Park
                                        Acton, MA, 01720
email: bmccann@indusriver.com           web: www.indusriver.com 
phone: (978) 266-8140                   fax: (978) 266-8111
References: