[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Heartbeats draft available
Hi Ricky,
Yet again, the complexity argument rears its ugly head. If you've been
following the previous discussion on this topic, I hope you understand why I
do not believe that measuring complexity is as simple as merely counting the
number of bits (or payloads or messages) on the wire.
Sending more messages can often help to eliminate uncertainty. In fact, one
of the best ways to reduce complexity is to tell the peer exactly what you
are going to do before you do it. I can give you lots of examples where the
lack of negotiation has made interoperability difficult. Take rekeying for
example. Other examples are available upon request.
Anyway, I really don't think it matters whether we do heartbeats in phase 1
or phase 2. That wasn't a requirement of my protocol. On the other hand,
providing a negotiation protocol was a definite requirement.
The negotiation protocol was specifically designed to be simple. Currently,
the negotiation protocol defines two options and one parameter. The syntax
of the negotiation is clear and there is no interaction between the fields.
The draft also explicitly spells out which peer has the final decision
regarding each field. The information is agreed on with minimal complexity
because there is no ambiguity.
BTW, I do not believe this feature is large enough to warrant a separate
requirements draft. However, if you want a list of requirements, read
sections 3 and 4 of the draft.
Also, if you want to see a list of features/services which may not
interoperate with your non-negotiated heartbeats proposal, I will prepare
one in time for Adelaide.
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: Monday, March 20, 2000 2:17 PM
> To: akrywani@newbridge.com
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Heartbeats draft available
>
>
> Howdy Andrew,
>
> In general, I am proposing a philosophy of "configure
> it if you want
> it, don't negotiate it". More comments interspersed.
>
>
> Andrew Krywaniuk wrote:
> >
> > > 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.
>
>
> You make a respectable point. The "just ping it"
> solution does require
> configuration to "do heartbeats". But the ping in band in phase 2 idea
> requires no extra implementation. Heartbeats could be specified in a
> "best current practice" draft. And this is the salient point of
> distinction between our proposals. Add a new option
> negotiating protocol
> which will could reduce configuration simplicity to "propose or don't
> propose heartbeats", or accept the confituration burden
> across mulitple
> vendors systems to allow in-band heartbeat pings and send the pings.
>
> >
> > 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).
>
>
> That's correct. Doing pings inside of a Phase 2 SA
> requires both peers
> to be configured to allow the traffic. Personally, for keepalive
> traffic, I think that explicit manual configuration is
> preferable to an
> option negotiation protocol.
>
> >
> > 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.
>
> Not so. Previously you mentioned that a peer may not
> want to allow the
> management traffic. While this is always a viable choice for
> a secrurity
> gateway, it does not imply that some implementations would be
> unable to
> allow management traffic. My proposal specifically says if
> you want the
> keepalives, you need to configure appropriate selectors on
> the security
> gateways. Any complient implementation would have no trouble adding
> selectors.
>
> >
> > 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.
>
>
> Configure it if you want it. Require nothing.
>
> >
> > 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.
>
>
> The arguments I am making are that adding a new option
> negotiating
> protocol is too complex for this problem and using phase 1
> SAs to verify
> the integrity of phase 2 SAs is needlesly indirect and unreliable. I
> therefore will refrain from extenting your proposal. (But thanks for
> offering :-)
>
>
> >
> > 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.
>
> I hear you. And I do respect and concure with this
> goal. And (let's be
> realistic here) this goal forces our proposals into competing
> with each
> other for the mind share of this WG. And maybe there are
> still yet other
> ideas out there which have yet to be voiced. I ardently hope
> that our WG
> can come away from this IETF with a unified intended
> direction toward a
> keepalive solution. But I expect that both you and I are in
> for a round
> of abuse for not having done a "requirements document" first.
>
>
> --
> Ricky Charlet : Redcreek Communications : usa (510) 795-6903
>
Follow-Ups:
References: