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

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


References: