[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on: draft-vlado-ipsec-keep-alive-00.txt
Well, I for one applaud the effort. Regardless of its technical merit, we
should be encouraging different ideas in the WG. So lets argue the technical
merits.
BTW: I thought at the end of the WG in Australia, that we were not sure if
this problem should be solved in the IPSec / IPSra space? Was there not a
point about what the problem we are trying to solve may not be something for
IPSec but for IP (Something like that).
Scott
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Vlado Zafirov
> Sent: Friday, June 30, 2000 12:20 PM
> To: andrew.krywaniuk@alcatel.com
> Cc: 'Stephane Beaulieu'; ipsec@lists.tislabs.com
> Subject: 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.
>
>
>
>
>