[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.
>
>
>
>
>