[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Heartbeats (was RE: keepalives)
We're seeing two different philosophies here, I think.
Send the keepalive/heartbeat via phase 1, or send it via phase 2's.
Phase 1 makes intuitive sense to me, if you include SPI information in the
keepalive, as I proposed previously. This comes at the cost of possibly
having to renegotiate the phase 1 SA more often than for rekeying, but is NOT
the same as continuous channel mode (which a lot of people are assuming).
If you send it via phase 2, you either need a separate SA for this, i.e. ONLY
for keepalives, or you send it via some existing ipsec SA.
For the record, I like neither of the phase 2 approaches (as if that wasn't
obvious). IPSEC SA's are for ipsec traffic, not for maintenance traffic,
meaning they are for bulk traffic. Do you really want to have to examine
every packet running through your SA (in the second case) as to whether this
is real ipsec traffic or maintenance traffic? You pay a performance penalty
for this, which I personally feel is not justified.
In the other case, where you have a special SA, you have to somehow identify
it as being special. I'd rather leave ipsec SA's carrying ipsec traffic, and
not make a 'special' SA, which looks like an ipsec SA, but isn't. Whether or
not a new DOI is the way to go or not, I'm not sure, but I don't think we
should abuse ipsec SA's for maintenance traffic. It needlessly complicates
it, which is counter to what many people believe about security protocols:
Simple is good; Complex is insecure.
I like the fact that we can just let the phase 1 die silently, without having
to keep it around for keepalives, and for this you'd need another phase 2 SA.
I'd just prefer to not call it a 'special ipsec SA'. That clutters up a lot
of things. Maybe there's better way to unambiguously distinguish this from a
ipsec Sa, other than via a new DOI. But I don't think it's just the traffic
that needs to be 'special' but the SA as well. Otherwise you'll have to
clutter up too much ipsec code (I think. I could be wrong).
Is that an accurate summary (with commentary)?
jan
On Tue, 7 Dec 1999, Walker, Jesse wrote:
> Why does it require a new DOI? Why can't we just define a new "heartbeat"
> application using, e.g., UDP port X? By definition the phase 2 SA in this
> scenario is end-to-end, and so to agree on its parameters within IKE we need
> to specify the protocol (and perhaps port number) used in the service. Why
> does this have to be any different than restricting end-to-end traffic on
> the SA to TCP port 23?
>
> -- Jesse
>
> -----Original Message-----
> From: Jan Vilhuber [mailto:vilhuber@cisco.com]
> Sent: Tuesday, December 07, 1999 1:14 PM
> To: Ricky Charlet
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Heartbeats (was RE: keepalives)
>
>
> On Tue, 7 Dec 1999, Ricky Charlet wrote:
> >
> > > I'm not sure what heartbeat packet is best, ISAKMP, transport ESP or
> > > 'hijacked' tunnelled ESP. I think this is a new protocol but I don't
> think
> > > it justifies an SA of its own. I think using an ISAKMP notification is
> best
> > > as most people seem to want this associated with the phase 1 SA.
> >
> >
> >
> > I'd like to see dead peer detection be in a dedicated IPsec SA pair
> per
> > peer pair. There are several good things about doing dead peer detection
> > this way:
> >
> This would require a new DOI, no? It's a dedicated phase 2 SA, but it's not
> (I claim) an ipsec SA. So a new DOI is needed.
>
> jan
>
>
>
> > * If there are multiple IKE or IPsec SAs to same peer, only need one
> > 'keepalive' session.
> >
> > * Allows IKE SAs to go away (or dangle the IPsec SAs) if an
> > implementation so wishes.
> >
> > * Does not interfere with packet counts or inactivity time outs of IKE
> > or other IPsec SAs.
> >
> > * IPsec may architecturally swap key management protocol without
> > worrying about loosing dead peer detection functions.
> >
> > * may be enabled or disabled per peer by policy
> >
> >
> >
> > Here is one negative that I can think of: If one peer reconfigures
> such
> > that some but not all current IPsec SAs become defunct, this scheme may
> > not detect that or may think all current SAs became defunct. This could
> > be engineered around with a dead peer recovery detection algorithm.
> >
> > --
> > ####################################
> > # Ricky Charlet
> > # (510) 795-6903
> > # rcharlet@redcreek.com
> > ####################################
> >
> > end Howdy;
> >
>
> --
> Jan Vilhuber vilhuber@cisco.com
> Cisco Systems, San Jose (408) 527-0847
>
>
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
Follow-Ups:
References: