[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on: draft-vlado-ipsec-keep-alive-00.txt
Andrew,
I am describing the use. If you think that it's a good idea to show more
examples and ways to use it I will do it.
I read you draft. It's great. Don't get me like competitor or enemy. I am
trying to do is give an idea. May be it is bad, may be not
Just go ahead with questions that you wanna see and let me try answer them.
Hey we're here to make the best possible standards available for IPsec, right?
Andrew Krywaniuk wrote:
> 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
> >
> >
> >
--
Vlado Zafirov
RADWare, INC
Technical Support Engineer
Tel: (202) 625-1505
Fax: (202) 625-1506
Confidentiality Note: This e-mail, and any attachment to it, contains privileged
and confidential information intended only for the use of the individual(s) or
entity
named in the e-mail. If the reader of this e-mail is not the intended recipient,
or the employee or agent responsible for delivering it to the intended
recipient, you are
hereby notified that reading it is strictly prohibited. If you have received
this e-mail in error, please immediately return it to the sender and delete it
from your system.
Thank you.
References: