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

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: