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

RE: Heartbeats draft available

> 	If the working group so feels, we could radify several
> heartbeat/keepalive mechanisms. In that case Andrew's/Tero's and my
> proposals are not competative. But if we think that is unweildy, or we
> are just too lazy and we only want one recommended keepalive
> mechanism,
> then choose your side or make up a new one and say your piece.

Hi Ricky,

Even though Tero and I were both amenable to the concept of phase 2
heartbeats, we thought it was more important to encourage interoperability
by keeping the number of standardized configuration options low.

Your proposal is indeed simple, but it requires knowledge about the peer's
configuration that you should not assume. (I notice that you made no mention
of a negotiation phase.) The peer may not want you to send traffic on a
hijacked SA, therefore it would be inappropriate to do so unless this was
negotiated (along with the various session parameters).

Unfortunately, for the reasons I mentioned previously, some implementations
would be unable to use your method. This makes it unsuitable for use as an
interoperability mode.

I don't see how you could fix this problem without, for example, requiring
that all IPsec SAs terminating at the public IP of the sgw be classified as
management SAs (with implied policy holes, accounting rules, and exemption
from inactivity timeouts). Unfortunately, I don't think the vendors already
sending L2TP traffic on this channel would play along.

There is a stipulation in the draft that new heartbeat types can be added,
but only if there is a clear need for a feature that cannot be provided by
the existing protocol. So if there is an essential need for a phase 2
heartbeat then we can add it to the draft later.

What we are trying to avoid here is the case where implementers feel
compelled to support each of the bajillion different heartbeat formats that
we had to add to the draft because we were trying to cater to every
individual.

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


> -----Original Message-----
> From: rcharlet@newbridge.com
> [mailto:rcharlet@newbridge.com]On Behalf Of
> Ricky Charlet
> Sent: Friday, March 17, 2000 1:16 PM
> To: akrywani@newbridge.com
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Heartbeats draft available
>
>
> Andrew Krywaniuk wrote:
> >
> > > While I
> > > readily agree
> > > that a simple tallying of the posts shows a majority arguing
> > > in favor of
> > > doing heartbeats in ISAKMP, could you please spend a little
> > > time anyway
> > > going over your justifications for this approach above the others.
> >
> > Hi Ricky,
> >
> > Let me first state that the draft specifies two things:
> >
> > a) A framework for negotiating and implementing heartbeats.
> > b) A default mode of operation that has been chosen for
> interoperability.
> >
> > If you want to define some other mode of operation for use
> with your own
> > products (e.g. phase 2 heartbeats), the framework lets you
> do this. Just
> > define a new heartbeat type from the private range,
> exchange vendor ids, and
> > you're set. Consenting parties can replace any of the 3
> layers we describe
> > in the draft.
> >
> > But as for part b, let's face it... When you're defining a standard
> > interoperability mode, vendor support DOES matter, and the
> majority of
> > support was for a phase 1 approach.
> >
> > Even when I talked to some of the vendors who do "dangle"
> phase 1 SAs, many
> > of them were still in favour of using phase 1 heartbeats.
> Most vendors who
> > dangle SAs say they do so only when they are low on memory,
> so they will
> > still be able to use heartbeats most of the time.
> >
> > We also wanted the default mode to be easy to understand and easy to
> > implement. With the heartbeat protocol, you can implement
> the bare minimum
> > set of requirements and still be guaranteed of
> interoperability with the
> > peer.
> >
> > Phase 2 heartbeats do have a number of advantages over
> phase 1 heartbeats,
> > but there are also a lot of added complications, which would make it
> > difficult to define a simple phase 2 heartbeat mode that is
> suitable for
> > interoperability.
> >
> > Some of the complications: using hijacked SAs (mixing
> customer traffic with
> > management traffic -- our customers don't like this),
> interactions with the
> > accounting service (requires two traffic counters), need
> for a policy hole
> > to allow the heartbeat traffic, negotiation of which exact
> SA parameters to
> > use, flexibility of packet format, potential of defeating the peer's
> > inactivity timeout mechanism.
> >
> > Allowing all of the common scenarios that various vendors
> want to support
> > would require a much more elaborate negotiation scheme. And
> it doesn't seem
> > fair to legislate all or most of the above behaviours.
> Which is why you are
> > free to define your own protocol for private use, at which
> point you can
> > make whatever assumptions you want about the peer's configuration.
> >
> > It's impossible to please everybody. But all things
> considered, I would
> > rather have a heartbeat protocol that has to be turned off
> under low memory
> > conditions than a protocol that causes interoperability
> nightmares because
> > it is too difficult to negotiate.
> >
> > Andrew
> > _______________________________________________
> >  Beauty without truth is insubstantial.
> >  Truth without beauty is unbearable.
>
>
> Howdy Andrew,
> 	You make some decent points and there well said. But
> I've pondered it a
> bit and I would like to advocate for using a much simpler mechanism,
> in-band in each phase 2 SA.
>
> PHASE 2 IN_BAND KEEPALIVE PROPOSAL:
> 	The mechanism is ping. The configuration requirements
> are that you
> allow one IP address each from your tunnel endpoint security
> gateways in
> among your endpoint lists so that the ping is protected by your phase2
> SA. You will have to suffer the keepalive traffic in your
> statistics be
> they used for monitoring and/or accounting.  As long as your SA is not
> otherwise receiving traffic, ping the peer gateway address once per
> configurable period X. After Y successive non-responses, mark
> the state
> of your SA as 'down'. Keep trying the pings and after Y
> successive good
> responses, mark the state as 'up'. Done. ( This idea is so
> simple that I
> do not claim authorship, I'm sure it came up on the list before. )
>
> 	If the working group so feels, we could radify several
> heartbeat/keepalive mechanisms. In that case Andrew's/Tero's and my
> proposals are not competative. But if we think that is unweildy, or we
> are just too lazy and we only want one recommended keepalive
> mechanism,
> then choose your side or make up a new one and say your piece.
>
>
>
> --
>   Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903
>
Follow-Ups: References: