[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Phase 1 KB lifetime



On Wed, 19 Jan 2000 14:36:37 EST you wrote
> >>>>> "Dan" == Dan Harkins <dharkins@network-alchemy.com> writes:
> 
>  Dan> On Wed, 19 Jan 2000 13:31:25 EST you wrote
>  >> ...
>  >> What about people who want to delete their phase 1s under low
>  >> memory conditions? ...
> 
>  Dan> Those are quite different that what you said. And it is not at
>  Dan> all what I said.
> 
>  Dan> You can delete your SAs anytime you want. You can set a panic
>  Dan> timer to reboot your box every hour on the hour. That does not
>  Dan> violate the protocol. What I was saying is that when someone
>  Dan> sends you a message telling you that the lifetime you just
>  Dan> negotiated should be less you should not just skip over it and
>  Dan> go merrrily on your way assuming that the SA will be deleted
>  Dan> when, in fact, it will not. That way lies problems.
> 
> If the other end tells you it's using a smaller lifetime and you
> ignore that message, this means you will be assuming the SA will not
> be delete when, in fact, it will be.  The reverse of what you said.

It is? I kinda thought that was exactly what I was saying. Do not ignore 
the message ("you should not skip over it") because that means that you'll 
be in that bad state ("That way lies problems").

> That puts the protocol in the same state as the examples Andrew
> mentioned.  Which is why I said what I said -- it seems overkill to
> add a protocol mechanism that blocks ONE of the possible transitions
> into state X without affecting a half dozen transitions into that same 
> state X.  Yes, as Shawn pointed out, state X is not a good place to
> be, since the protocol doesn't necessarily recover nicely.  But as
> you said, you are allowed to go there.

If state X is bad and there is a a way to prevent you from getting into
state X-- it isn't a 100% solution but it is a partial solution to a
very common way to get into state X-- why would you not want to do it?

>  Dan> I'm not talking about forbidding perfectly common sense things
>  Dan> (which, by the way don't really have much to do with the
>  Dan> protocol) I'm talking about requiring perfectly common sense
>  Dan> things (which do).
> 
> That depends on which aspect of common sense you're after.
> 
> One aspect says "take action on all the information you have".  This
> is what you advocate.
> 
> Another view says "do not add complexity if doing so doesn't gain you
> much".  This is my point -- the global state machine still has the
> same number of states, and in particular still has the same
> undesirable state.  There are still plenty of ways to get into that
> state. 

As someone who's implemented this feature (twice) I can tell you it's
not that complicated. You're parsing the offer anyway so you know the
lifetime. You presumably know your configured lifetime. If the latter
is less than the former add a notify to your response. There may be
plenty of ways to get in a screwed up state but one of the most common
ways is no longer possible. 

It's possible to get in a screwed up state but that doesn't mean that
efforts shouldn't be taken to prevent one from getting there. There are
numerous ways I can wreck my car but that fact doesn't mean that I should
ignore traffic signs.

  Dan.



References: