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

RE: Heartbeats draft available



Hi Scott,

What Tero said is correct. Using the SA payload as a negotiation protocol
for other features is undesirable for many reasons.

First, there is the fact that the payload uses a flat proposal syntax. This
means that the number of proposals in the list is the permutation of all the
options. Adding even a boolean parameter to the negotiation
(heartbeats=yes/no) would double the number of proposals required.

As Tero mentioned, we could remove this problem by removing the requirement
that the SA proposal cannot be modified (thus moving away from the flat
model), but this has a number of undesirable properties as well.

First, it makes IKE even less stateless than it is right now.

Also, there is the issue of vendor ids. [EXT-METH] states that
implementations MUST NOT send payloads of a private type unless both parties
have both sent and received a familiar vendor ID. Since the SA proposals are
sent in the first message of the phase 1 exchange, it seems inappropriate to
negotiate heartbeats (an experimental protocol) before the vendor id has
been received.

Admittedly, this is not true if you are suggesting that we negotiate
heartbeats as part of the QM proposal, but that would bind the heartbeat
negotiation to the IPsec SA instead of to the connection, which is not what
we want. That would violate the rule I mentioned in my previous message of
reducing complexity by stating what you want to do and then doing it. (Is
this rationale clear? I can go into more detail if it isn't.)

Finally, one of the requirements of the draft is to provide a flexible
negotiation scheme for the heartbeats.

I think many people in this WG would agree that the absence of a
standardized configuration protocol is hurting IPsec. Right now,
ISAKMP-Config is the leading contender for that position, which is why I am
proposing to use it.

I don't see a problem with using ISAKMP-Config; it is simple and secure. But
if, for whatever reason, the WG is unhappy with ISAKMP-Config, then let
someone write a draft describing their own configuration protocol. If the WG
chooses to ratify a different configuration protocol instead ISAKMP-Config
then we will certainly change the draft to reflect this.

Trying to avoid the issue of negotiation by way of a kludge like you are
suggesting is a false economy. It may seem like a simple solution right now,
but the sum of many simple, kludgy solutions equals one horrendous mess.

BTW, I would consider heartbeats to be a feature of the connection, and not
a feature of the SA. That is why I said that I didn't think it was important
whether they were sent in phase 1 or phase 2.

Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.


> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@ssh.fi]
> Sent: Tuesday, March 21, 2000 11:16 PM
> To: Scott G. Kelly
> Cc: Andrew Krywaniuk; 'Ricky Charlet'; ipsec@lists.tislabs.com
> Subject: Re: Heartbeats draft available
>
>
> Scott G. Kelly writes:
> > Whether "heartbeats" are sent in a phase 1 or phase 2 SA, they are
> > essentially a feature of the SA. Features of SAs are currently
> > configured (and negotiated) using SA attributes. Why would
> these be any
> > different?
>
> Because SA payloads does not allow responder to modify the proposal.
> In heartbeat protocol this is almost mandatory feature, because the
> responder is the one who is going to send the packets, thus he wants
> to control the parameters.
>
> Of course we could say that when using this special heartbeat
> negotiation protocol, the responder is allowed to modify the SA, but
> the SA payload is also little too complicated for very basic
> negotiation (all the things about transforms, protocols and
> proposals).
> --
> kivinen@iki.fi                               Work : +358-9-4354 3218
> SSH Communications Security                  http://www.ssh.fi/
> SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
>



Follow-Ups: