[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on: draft-vlado-ipsec-keep-alive-00.txt
My comment on complexity:
There is syntactic complexity and there is operational complexity. It is
possible to trade off one for the other.
My draft attempts to answer the question "How do you deal with situation X?"
for all scenerios that were expounded on this list. Therefore, it is long
but very precise. It's operation is simplified because there is no
ambiguity.
Vlado's draft is short (when you remove all the dead weight) and
syntactically very simple because it only describes the message format and
not its use. It remains to be seen whether its operation will still appear
simple when multiple vendors' differing applications of the protocol are
permuted against our already very divergent implementations of IKE.
Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Vlado
> Sent: Thursday, June 29, 2000 3:17 PM
> To: Scott G. Kelly
> Cc: Stephane Beaulieu; ipsec@lists.tislabs.com
> Subject: Re: Comments on: draft-vlado-ipsec-keep-alive-00.txt
>
>
> Hi Scott,
> I don't thnk so. I think this simpler alogirthm is doing
> the same job with less
> bandwith, faster processing AND EASY implementation. There is
> some things to be added
>
> 1. Negotiation (this is only for backward compability) - This
> can easy. The software
> can have option - keep-alive on,off,auto. In auto mode
> initiator sends keep-alive
> packets, if he receives ISAKMP
> Info message UNSUPPORTED-EXCHANGE-TYPE then he knows the
> other end doesn't support
> that exchange.
>
> 2. This can be further updated with rule: use keep-alive when
> there is no traffic for
> that SA for certain amount of time, default equal to the
> keep-alive time.
>
>
> "Scott G. Kelly" wrote:
>
> > Comments below -
> >
> > Vlado Zafirov wrote:
> > >
> > > Hi Stephane,
> > > Well that's my first internet-draft I ever
> published so please excuse me
> > > for any mistakes I made.
> > >
> > > I meant to make very simple, low-bandwidth and easy to
> implement exchange.
> > >
> > > I read very fast the proposal draft that you was so kind
> to send me. It' very
> > > very good. However I believe too complicated and needs a
> lot of work
> > > to be implemented and it's pretty bandwidth intesive.
> > >
> > > About comments:
> > > 1. Yes, it's not a problem. I will make that change
> and resubmit the draft.
> > > However when Client dies it's just simple mater of
> reconnecting. Usually
> > > problem is when Secure Gateway loose connection
> because it's should be
> > > restarted or this connection dropped manually.
> > >
> > > 2. I didn't thought of that and I was not aware of
> that practice. Thank you
> > > so much for the feedback. This will be changed too.
> > >
> > > Stephane Beaulieu wrote:
> > >
> > > > Hi Vlado,
> > > >
> > > > I'm not sure if you were aware of it, but there is
> another Internet-Draft
> > > > whose goal it is to provide the same functionality. See
> > > > http://www.vpnc.org/draft-ietf-ipsec-heartbeats
> > > >
> > > > It has received quite a bit of feedback, and I think
> that most people are
> > > > pretty satisfied with it.
> >
> > This is absolute nonsense. Take a straw poll right now.
> >
> > <much trimmed after this...>
> >
> > All in all, I think the rough consensus was that a much simpler
> > mechanism would suffice.
> >
> > Scott
>
>
>
Follow-Ups:
References: