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

RE: IPSec SA DELETE in "dangling" implementation



Dan (and Tero)

I have never said I counted on *receiving* a delete payload. If it appeared
that I did, it was not intended.

I assume I always want to *send* a delete payload. That's the basis for many
of my suggestions. And that is in part because I recognize that the other
end may not have the same expirations as I do. It also may not transfer its
traffic to a new SA the same way I do. I might decide to terminate the SA
prematurely.

The transmission of deletes helps in these cases, since it at least creates
a chance that the peer can figure out what's happening sooner.

However, since that is optional, you're absolutely correct, we have to be
able to deal with those conditions where they are not sent (or are dropped
anyway.) And we do try to deal with it. I'm looking forward to a
standards-based keep-alive or heartbeat or peer-viability indicator or
whatever we're going to call it.

The bottom line is that you treat the usage of responder-lifetime the same
way I treat the *transmission* of deletes. Yet, you're right, they're both
optional. And even if you do one, there are still benefits in doing the
other. They aren't mutually exclusive.

In any case, I've already said I'm not going to actively promote the
continuous channel model anymore. I'm rewriting the re-keying document to
reflect this.

Tim

---
Tim Jenkins                       TimeStep Corporation
tjenkins@timestep.com          http://www.timestep.com
(613) 599-3610 x4304               Fax: (613) 599-3617



> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@network-alchemy.com]
> Sent: December 2, 1999 4:03 PM
> To: Tim Jenkins
> Cc: ipsec@lists.tislabs.com
> Subject: Re: IPSec SA DELETE in "dangling" implementation 
> 
> 
>   Please re-read this after s/responder-lifetime/delete payload/g.
> 
>   How do you intend on interoperating with someone who never sends
> a delete payload and doesn't process them? What will you tell
> the customer? "Is one of them violating the specifications?"
> 
>   Allow me to point out that the observation "but everyone implements
> the delete payload" is countered by your second statement.
> 
>   It seems to me that one can avoid all these rekeying issues by
> simply implementing a very common sense feature in the protocol or
> one avoid them by implementing a very complex, (let me use this term 
> again because I love it) Rube Goldbergian system.
> 
>   Dan.
> 
> On Thu, 02 Dec 1999 15:30:31 EST you wrote
> > > -----Original Message-----
> > > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM]
> > > Sent: December 2, 1999 3:15 PM
> > > To: Tim Jenkins
> > > Cc: ipsec@lists.tislabs.com
> > > Subject: Re: IPSec SA DELETE in "dangling" implementation 
> > > 
> > > 
> > > On Thu, 02 Dec 1999 15:05:39 EST you wrote
> > oo.
> > > 
> > > I'll ask again: why wouldn't anyone use the responder-lifetime
> > > notify for lifetimes which are greater than the configured value
> > > and respect the lifetimes of offers which are less than the
> > > configured value? 
> > 
> > The reasons are irrelevant. The simple fact is that you might
> > have to interoperate with an implementation that legally doesn't
> > do that.
> > 
> > If you make the assumption that every implementation does that,
> > there's a potential interoperability problem. If you don't care
> > about interoperating with those implementations, then I guess
> > that's your choice. But in the customer's eyes, there's a chance
> > either implementation or both are going to look bad. And in
> > either case, it makes IPsec look bad.
> > 
> > (Customer: Is one violating the specifications?
> >  Answer: No.
> >  Customer: But they don't work together!!!
> >  Answer: Well, only under certain circumstances....)
> > 
> > > 
> > >   Dan.
> > > 
>