[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on: draft-vlado-ipsec-keep-alive-00.txt
Hi Vlado,
You could get an idea of the issues to which I am referring by browsing the
archives of this list for December, February, and March.
Some of the issues:
- Is the protocol self-stabilizing?
- How does the protocol deal with DoS (or even DDoS) attempts? (and how do
we ensure that a poor implementation cannot help to effect a DoS attack on
the peer?)
- Can the processing of the messages be optimized by not using encyption?
- How does the protocol deal with so-called "dangling" phase 2s? (ipsec sa's
that persist after the isakmp sa has been deleted)
- How do we deal with very low bandwidth peers (e.g. wireless)?
- What do we do if the peer wants to drop the link layer connection without
deleting the sa?
- How should the protocol be used in conjunction with load sharing?
- How can the protocol be revised later?
- How SHOULD the protocol actually be used?
Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.
> -----Original Message-----
> From: Vlado Zafirov [mailto:vladoz@radware.com]
> Sent: Friday, June 30, 2000 3: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.
>
>
>